Video memory access method, device, equipment, system and computer storage medium

Abstract

Embodiments of the present application provide a graphics memory access method, device, equipment, system and computer storage medium. The method comprises: obtaining a data access request sent by a first graphics processing unit (GPU), the data access request being used for accessing a graphics memory space of a second GPU, and the data access request comprising a virtual address of the first GPU; determining a graphics memory window mapping table and an access page table based on the data access request, the graphics memory window mapping table comprising a mapping relationship between a memory mapping input / output (MMIO) address of a base address register and a graphics memory address of the second GPU, and the access page table comprising a mapping relationship between the virtual address of the first GPU and the MMIO address; and accessing the graphics memory space of the second GPU based on the access page table and the graphics memory window mapping table. In the embodiments, direct access operation between GPU graphics memories is effectively implemented, and data transmission delay is effectively reduced.

Description

Technical Field

[0001] This application relates to the field of video memory technology, and in particular to a video memory access method, apparatus, device, system, and computer storage medium. Background Technology

[0002] In recent years, data transfer between Graphics Processing Units (GPUs) has gradually become a bottleneck in the development of multi-GPU high-performance computing systems. Currently, for some types of GPUs, there is no direct data transfer capability between GPUs; traditionally, data exchange between GPUs typically occurs through the processor's (Central Processing Unit, CPU) memory.

[0003] However, large amounts of data need to be transferred through the CPU and memory, which suffers from high latency and limited bandwidth, thus easily leading to low data transmission efficiency. Summary of the Invention

[0004] This application provides a method, apparatus, device, system, and computer storage medium for accessing video memory, which can directly enable direct access operations between GPU video memory without the need for CPU intermediary, thereby improving the system performance of multi-GPU systems and reducing data transmission latency.

[0005] This invention provides a method for accessing video memory, including:

[0006] Obtain a data access request sent by the first graphics processing unit (GPU), the data access request being used to access the video memory space of the second GPU, the data access request including the virtual address of the first GPU;

[0007] Based on the data access request, a video memory window mapping table and an access page table are determined. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address.

[0008] The memory space of the second GPU is accessed based on the access page table and the memory window mapping table.

[0009] This invention provides a video memory access device, comprising:

[0010] The first acquisition module is used to acquire a data access request sent by the first graphics processing unit (GPU), the data access request being used to access the video memory space of the second GPU, and the data access request including the virtual address of the first GPU.

[0011] The first determining module is used to determine a video memory window mapping table and an access page table based on the data access request. The video memory window mapping table includes a mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The access page table includes a mapping relationship between the virtual address of the first GPU and the MMIO address.

[0012] The first processing module is used to access the memory space of the second GPU based on the access page table and the memory window mapping table.

[0013] This invention provides a video memory access system, including: a graphics processing unit (GPU) driver module and multiple GPUs communicatively connected to the GPU driver module, wherein the multiple GPUs include a first GPU and a second GPU;

[0014] The first GPU is used to send a data access request, the data access request being used to access the video memory space of the second GPU, and the data access request including the virtual address of the first GPU;

[0015] The GPU driver module is used to acquire the data access request, determine the memory window mapping table and the access page table. The memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the memory address of the second GPU. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address. The second GPU's memory space is accessed based on the access page table and the memory window mapping table.

[0016] This invention provides an electronic device, including: a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the method in the first aspect described above.

[0017] This invention provides a computer storage medium for storing a computer program that, when executed by a computer, implements the method described in the first aspect above.

[0018] This invention provides a computer program product, including: a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the method in the first aspect described above.

[0019] The memory access method, apparatus, device, system, and computer storage medium provided in this embodiment obtain data access requests sent by the first GPU, determine the memory window mapping table and access page table corresponding to the data access requests, and then access the memory space of the second GPU based on the access page table and the memory window mapping table. This effectively realizes point-to-point access operations between GPU memory without CPU relay. This not only improves the system performance of communication operations between multiple GPU memory, but also solves the problem of low data transmission efficiency caused by "bandwidth priority and high latency", reducing the latency of data transmission operations between GPU memory. In addition, this solution does not require modification of the application code information of the first or second GPU, thereby significantly reducing the maintenance cost and usage threshold of the GPU, further improving the practicality of the method. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 A schematic diagram illustrating a scenario of a video memory access method provided for an exemplary embodiment of this application;

[0022] Figure 2 A flowchart illustrating a video memory access method provided for an exemplary embodiment of this application;

[0023] Figure 3 A flowchart illustrating the process of determining a video memory window mapping table corresponding to the data access request, provided for an exemplary embodiment of this application;

[0024] Figure 4 A flowchart illustrating the process of determining the dynamic window mapping table corresponding to the second GPU as the video memory window mapping table, provided for an exemplary embodiment of this application;

[0025] Figure 5 A flowchart illustrating an exemplary application embodiment of this application for a method of inter-GPU memory access;

[0026] Figure 6 A schematic diagram of the structure of a video memory access device provided for an exemplary embodiment of this application;

[0027] Figure 7 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application;

[0028] Figure 8 This is a schematic diagram of a video memory access system provided for an exemplary embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

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

[0031] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.

[0032] To facilitate understanding of the video memory access method, apparatus, device, system, and computer storage medium provided in the embodiments of this application, the relevant technologies are briefly described below:

[0033] In recent years, data transfer between Graphics Processing Units (GPUs) has gradually become a bottleneck in the development of multi-GPU high-performance computing systems. Existing hardware platforms offer very limited support for direct communication between GPUs. A large number of GPU models that do not support native Peripheral Component Interconnect Express (PCIe) peer-to-peer (P2P) communication are widely deployed in the market, preventing these systems from fully realizing the performance potential of multi-GPU collaboration. This not only wastes GPU computing resources but also limits the effective utilization of system resources such as CPU, memory, and PCIe bandwidth.

[0034] In order to enable communication between GPU memory, a method of using the processor (Central Processing Unit, or CPU) memory is provided to facilitate data transfer between GPUs. Traditionally, data exchange between GPUs can be relayed through the CPU memory.

[0035] However, since a large amount of data needs to be transferred via CPU memory, this not only easily leads to low data transfer efficiency, but also suffers from high latency and limited bandwidth. These issues are particularly pronounced in AI applications. During the training of deep learning models, the distributed training operations across multiple GPUs require frequent gradient synchronization and parameter updates. The traditional method of transferring data between GPUs via CPU relay easily results in excessively high communication latency, severely impacting training efficiency. Furthermore, in large-scale model inference applications, model parameters often need to be distributed across GPUs, and the transmission latency of intermediate results during inference directly affects the overall response time. The CPU relay method is insufficient to meet the low-latency requirements of real-time inference.

[0036] To address the aforementioned technical problems, embodiments of this application provide a video memory access method, apparatus, device, system, and computer storage medium, as detailed in the appendix. Figure 1As shown, the execution entity of this video memory access method can be a video memory access device, which can be implemented as a local server, a cloud server, a mobile phone, a personal computer (PC), a tablet computer, a configuration application, etc. When the video memory access device is implemented as a cloud server, this video memory access method can be executed in the cloud. Several computing processes (cloud servers) can be deployed in the cloud, each with computing and storage resources. In the cloud, multiple computing processes can be organized to provide a certain service; of course, a single computing process can also provide one or more services. The cloud can provide this service by providing a service interface, which users call to use the corresponding service. Service interfaces include Software Development Kits (SDKs), Application Programming Interfaces (APIs), etc.

[0037] In some instances, the video memory access device can be implemented as a GPU driver 200, which can be communicatively connected to one or more GPUs to drive the one or more GPUs to perform corresponding data processing operations. The following description uses the GPU driver 200 as a video memory access device and multiple GPUs, including a first GPU 100 and a second GPU 300, as an example. The GPU driver 200 is communicatively connected to both the first GPU 100 and the second GPU 300.

[0038] In this embodiment, the first GPU 100 is used by a user to generate or obtain data access requests for the second GPU 300. The data access requests are used to access the video memory space of the second GPU and include the virtual address of the first GPU. Since the first GPU 100 and the second GPU 300 cannot directly access each other's video memory, the first GPU 100 can send the generated data access requests to the GPU driver device 200 so that point-to-point access operations between the video memory of the second GPU 300 can be achieved through the GPU driver device 200.

[0039] The GPU driver 200 is used to acquire data access requests sent by the first GPU 100, and determine the memory window mapping table and access page table corresponding to the data access requests. The memory window mapping table can be located in the second GPU 300. Specifically, the memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) addresses of the base address register and the memory addresses of the second GPU 300. For example, the memory window mapping table may include the mapping relationship between MMIO address 1 and memory address 1, MMIO address 2 and memory address 2, MMIO address 3 and memory address 3, MMIO address 4 and memory address 4, etc. The access page table can be located in the first GPU 100. Specifically, the access page table includes the mapping relationship between the virtual addresses of the first GPU 100 and the MMIO addresses, where the MMIO addresses correspond to the second GPU 300. For example, the access page table may include the mapping relationship between virtual address 1 and MMIO address 1, virtual address 2 and MMIO address 2, virtual address 3 and MMIO address 3, virtual address 4 and MMIO address 4, etc.

[0040] After determining the memory window mapping table and access page table corresponding to the data access request, the access page table and memory window mapping table can be analyzed and processed. By translating the MMIO addresses in the access page table and memory window mapping table, the mapping relationship between the virtual address of the first GPU 100 and the memory address of the second GPU 300 in the data access request can be directly obtained. Thus, the data access request can be sent to the second GPU 300, thereby enabling the first GPU 100 to access the memory space of the second GPU 300 through the data access request.

[0041] In this embodiment, P2P communication between GPUs is effectively enabled via PCIe operations. Specifically, data access requests are sent to the second GPU 300 through a memory window mapping table and access page table corresponding to the data access request. This allows for direct access between GPU memory without CPU intermediaries, improving system performance for communication between multiple GPUs and reducing data transfer latency. Furthermore, this solution does not require modification of the application code of the first GPU 100 or the second GPU 300, significantly reducing GPU maintenance costs and lowering the barrier to entry, thus enhancing the practicality of the method.

[0042] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0043] Figure 2A flowchart illustrating a video memory access method provided as an exemplary embodiment of this application; see attached diagram. Figure 2 As shown, this embodiment provides a video memory access method. The execution subject of this method is a video memory access device, which can be implemented as software or a combination of software and hardware. When the video memory access device is implemented as hardware, it can be various electronic devices capable of performing video memory access operations, including but not limited to personal computers, servers, driver access devices, etc. When the video memory access device is implemented as software, it can be installed in the electronic devices listed above. In some instances, the video memory access device can be implemented as a GPU driver or a GPU driver engine. In this case, the video memory access method provided in this embodiment can include:

[0044] Step S201: Obtain a data access request sent by the first graphics processing unit (GPU). The data access request is used to access the video memory space of the second GPU. The data access request includes the virtual address of the first GPU.

[0045] Step S202: Based on the data access request, determine the video memory window mapping table and the access page table. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address.

[0046] Step S203: Access the memory space of the second GPU based on the access page table and the memory window mapping table.

[0047] The specific implementation methods and principles of each of the above steps are explained in detail below:

[0048] Step S201: Obtain a data access request sent by the first graphics processing unit (GPU). The data access request is used to access the video memory space of the second GPU. The data access request includes the virtual address of the first GPU.

[0049] The memory access device is connected to a first GPU and a second GPU. The first GPU and the second GPU are different GPUs, and the first GPU and the second GPU do not have the ability to communicate directly in P2P. In this case, P2P direct communication can be achieved through PCIe operation (essentially through reading and writing MMIO). Specifically, when the first GPU has a data access requirement for the second GPU, the first GPU can generate or obtain a data access request. In order to ensure the quality and efficiency of data transfer operations between GPU memory, the data access request can be sent to the memory access device. The memory access device can obtain the data access request sent by the first GPU. The data access request is used to access the memory space of the second GPU, and the data access request may include the virtual address of the first GPU.

[0050] Step S202: Based on the data access request, determine the video memory window mapping table and the access page table. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address.

[0051] After receiving a data access request, in order to accurately implement direct data transfer operations between the first GPU and the second GPU based on the data access request, a memory window mapping table corresponding to the data access request can be determined. This memory window mapping table can be mapped to the pre-allocated physical memory BAR (Base Memory Area) of all the memory of the second GPU. Corresponding to the AddressRegister window, the BAR mentioned above is a register in the PCIe device configuration space, used to specify a memory-mapped I / O (MMIO) region of the device. It is typically used for the GPU's command buffer, control register, or memory mapping window. The BAR window can be implemented as any of the following: BAR1 window, BAR2 window, or BAR3 window, etc. For ease of understanding, the following explanation uses the BAR1 window as an example. In this case, the memory window mapping table can include the mapping relationship between the MMIO address of the base address register and the memory address of the second GPU. The memory window mapping table can be located in the second GPU. Specifically, the mapping relationship included in the memory window mapping table can be implemented as a fixed static mapping relationship, in which case the memory window mapping table can be implemented as a static mapping table; or, the mapping relationship included in the memory window mapping table can be implemented as a dynamically variable dynamic mapping relationship, in which case the memory window mapping table can be implemented as a dynamic mapping table.

[0052] For memory window mapping tables, since different types of memory window mapping tables have different determination methods, in some instances, when the memory window mapping table is implemented as a static mapping table, the memory window mapping table can be pre-configured and stored in a preset area. In this case, the memory window mapping table can be obtained by accessing the preset area, which effectively ensures the accuracy and reliability of determining the memory window mapping table.

[0053] In other instances, where the memory window mapping table is implemented as a dynamic mapping table, determining the memory window mapping table corresponding to a data access request may include: obtaining the memory-mapped input / output (MMIO) address of the base address register and the memory address of the second GPU based on the data access request; then dynamically constructing a mapping relationship based on the MMIO address and the memory address of the second GPU; and determining the memory window mapping table based on the mapping relationship. This effectively ensures the accuracy and reliability of determining the memory window mapping table.

[0054] For data access requests, in order to accurately implement data transfer operations between the first GPU and the second GPU based on the data access requests, it is necessary to determine not only the memory window mapping table corresponding to the data access request, but also the access page table corresponding to the data access request. This access page table is used to implement direct access operations to the GPU memory for the second GPU. Specifically, the access page table can include the mapping relationship between the virtual address and MMIO address of the first GPU. Furthermore, the mapping relationship included in the access page table can be implemented as a fixed mapping relationship, in which case the memory window mapping table can be implemented as a static mapping table; or, the mapping relationship included in the access page table can be implemented as a dynamically variable mapping relationship, in which case the access page table can be implemented as a dynamic mapping table.

[0055] In some instances, when the access page table is a static mapping table, the access page table can be pre-configured and stored in a preset area. In this case, the access page table can be obtained by accessing the preset area, which effectively ensures the accuracy and reliability of determining the access page table.

[0056] In other instances, where the access page table is a dynamic mapping table, determining the access page table corresponding to a data access request may include: obtaining the memory-mapped input / output (MMIO) address of the base address register and the virtual address of the first GPU based on the data access request; then dynamically constructing a mapping relationship based on the MMIO address and the virtual address of the first GPU; and determining the access page table based on the mapping relationship. This effectively ensures the accuracy and reliability of determining the access page table.

[0057] Step S203: Access the memory space of the second GPU based on the access page table and the memory window mapping table.

[0058] Since the memory window mapping table includes the mapping relationship between MMIO addresses and the memory addresses of the second GPU, and the access page table includes the mapping relationship between the virtual addresses of the first GPU and the MMIO addresses, the correspondence between the memory addresses of the second GPU and the virtual addresses of the first GPU can be determined through address translation operations of MMIO addresses. Therefore, after determining the memory window mapping table and the access page table corresponding to the data access request, data access operations can be performed based on the access page table and the memory window mapping table. That is, data access requests can access the memory of the second GPU based on the correspondence between the virtual addresses of the first GPU and the memory addresses of the second GPU, thereby effectively realizing point-to-point communication operations between the first GPU and the second GPU.

[0059] Furthermore, after accessing the memory space of the second GPU based on the access page table and the memory window mapping table, in order to improve the effective utilization of data resources, the MMIO information in the memory window mapping table can be managed or released according to the access operation of the memory space of the second GPU. At this time, the method in this embodiment may also include: when the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, determining the access status of the data access request; when the access status is a completed status, releasing the temporary MMIO address in the access page table and the temporary MMIO address in the dynamic window mapping table.

[0060] Specifically, after accessing the memory space of the second GPU, and assuming the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, the access status of the data access request can be determined first. The access status can include a completed or incomplete state. If the access status is incomplete, it means the dynamic window mapping table and the access page table have not been fully applied, and no resource release operations can be performed on them. If the access status is completed, it means the dynamic window mapping table and the access page table have been fully applied. In this case, to improve the effective utilization of data resources, the temporary MMIO addresses in the access page table and the dynamic window mapping table can be released. This effectively allows for flexible management and release of the temporary MMIO addresses in the dynamic window mapping table and the access page table based on the access status of the data access request after the application of the dynamic window mapping table and the access page table is complete, further improving the flexibility and reliability of the method.

[0061] The memory access method provided in this embodiment obtains the data access request sent by the first GPU, determines the memory window mapping table and access page table corresponding to the data access request, and then accesses the memory space of the second GPU based on the access page table and the memory window mapping table. This effectively realizes point-to-point access operations between GPU memory without the need for CPU relay. This not only improves the system performance of communication operations between multiple GPU memory, but also solves the problem of low data transmission efficiency caused by "bandwidth priority and high latency", reducing the latency of data transmission operations between GPU memory. In addition, this solution does not require modification of the application code information of the first or second GPU, thereby significantly reducing the maintenance cost and usage threshold of the GPU, further improving the practicality of the method.

[0062] Figure 3 A flowchart illustrating the determination of a video memory window mapping table corresponding to a data access request is provided as an exemplary embodiment of this application; based on the above embodiment, refer to the appendix. Figure 3 As shown, the video memory window mapping table can be obtained not only by directly accessing a preset region, but also by determining it based on the management mode of the base address register. In this case, determining the video memory window mapping table corresponding to the data access request can include:

[0063] Step S301: Determine the management mode of the base address register based on the data access request.

[0064] The second GPU corresponds to the base address register, which is used to implement device access operations. It can include a physical memory window for allocating memory space to the second GPU, and this physical memory window can correspond to a memory-mapped input / output (MMIO) address (or BAR1 address). The base address register can have different management modes, such as dynamic mode and static mode. In some instances, the management mode of the base address register can be determined based on its management configuration data. This management configuration data can be pre-configured data, default configuration data, or data generated based on human-machine configuration operations. The management mode of the base address memory can be determined later based on the management configuration data. For example, when the management configuration data is "0", the management mode of the base address register is determined to be static mode; when the management configuration data is "1", the management mode of the base address register is determined to be dynamic mode.

[0065] In some instances, different management modes correspond to different address allocation methods for MMIO addresses, resulting in different methods for determining the memory window mapping table. Therefore, to accurately determine the memory window mapping table corresponding to the second GPU, after obtaining the data access request, the data access request can be analyzed and processed to determine the management mode of the base address register. Specifically, the management mode of the base address register can be determined by the management mode identifier of the second GPU. In this case, determining the management mode of the base address register based on the data access request can include: determining the management mode identifier corresponding to the second GPU based on the data access request; and determining the management mode of the base address register based on the management mode identifier.

[0066] The data access request may include a management mode identifier corresponding to the second GPU. After obtaining the data access request, the management mode identifier can be extracted from the data access request, thereby reliably determining the management mode identifier corresponding to the second GPU. Alternatively, the data access request may correspond to a management mode identifier corresponding to the second GPU. After obtaining the data access request, the management mode identifier corresponding to the second GPU can be determined based on the above mapping relationship and the data access request.

[0067] After determining the management mode identifier corresponding to the second GPU, the management mode identifier can be analyzed and processed to determine the management mode of the base address register. Specifically, determining the management mode of the base address register based on the management mode identifier can include: if the management mode identifier is a first preset identifier, determining the management mode of the base address register as static mode; if the management mode identifier is a second preset identifier, determining the management mode of the base address register as dynamic mode.

[0068] Step S302: Based on the management mode, determine the memory window mapping table corresponding to the second GPU.

[0069] Since different management modes correspond to different memory window mapping tables, after determining the management mode of the base address register, the memory window mapping table corresponding to the second GPU can be determined based on the management mode of the base address register. In some instances, determining the memory window mapping table corresponding to the second GPU based on the management mode can include: when the management mode is static, determining the static window mapping table corresponding to the second GPU as the memory window mapping table, where the mapping relationships in the static window mapping table remain fixed; when the management mode is dynamic, determining the dynamic window mapping table corresponding to the second GPU as the memory window mapping table, where the mapping relationships in the dynamic window mapping table are dynamically variable. This effectively allows for the determination of different memory window mapping tables corresponding to the second GPU based on different management modes.

[0070] In the case of static management mode, the mapping relationship in the static window mapping table corresponding to the second GPU remains fixed. Therefore, in order to improve the quality and effect of access operations between GPU memory, the static window mapping table can be pre-constructed. In this case, before determining the static window mapping table corresponding to the second GPU as the memory window mapping table, the method in this embodiment may further include: determining the memory address of the second GPU and the MMIO address to be allocated in the base address register; and constructing the static window mapping table based on the MMIO address to be allocated and the memory address.

[0071] For the memory window mapping table, before determining the static window mapping table corresponding to the second GPU as the memory window mapping table, the memory address of the second GPU and the MMIO address to be allocated in the base address register can be determined first. The memory of the second GPU is used to store all the data required by the GPU when performing computing tasks. The MMIO address to be allocated in the base address register can be a range pre-allocated to the second GPU. The range corresponding to the MMIO address to be allocated in the base address register can be dynamically adjusted based on preset operating system parameters. The second GPU in different scenarios can correspond to the range corresponding to the MMIO address to be allocated in the base address register of different sizes, which can meet the memory access requirements of different scenarios.

[0072] After determining the memory address of the second GPU and the MMIO address to be allocated in the base address register, multiple fixed mapping relationships can be constructed based on the MMIO address to be allocated and the memory address. Then, a static window mapping table can be constructed based on the multiple fixed mapping relationships, which effectively ensures the accuracy and reliability of determining the static window mapping table.

[0073] In other instances, since the static window mapping table is constructed based on the mapping relationship between the MMIO address to be allocated and the video memory address, there can be different space size relationships between the register space corresponding to the MMIO address to be allocated and the video memory space corresponding to the video memory address. For example, the register space corresponding to the MMIO address to be allocated may be greater than or equal to the video memory space corresponding to the video memory address; or the register space corresponding to the MMIO address to be allocated may be less than the video memory space corresponding to the video memory address. Different space size relationships can directly affect the creation operation of the static window mapping table. Therefore, constructing the static window mapping table based on the MMIO address to be allocated and the video memory address includes: determining the register space of the base address register and the video memory space of the second GPU; and constructing the static window mapping table based on the MMIO address to be allocated and the video memory address when the register space is greater than or equal to the video memory space.

[0074] In order to accurately construct the static window mapping table, the register space of the base address register and the video memory space of the second GPU can be determined. The register space can be determined by scanning the base address register, and the video memory space can be determined by scanning the second GPU.

[0075] After determining the register space of the base address register and the video memory space of the second GPU, a comparison operation can be performed on the size of the register space and the video memory space. If the register space is greater than or equal to the video memory space, it means that the MMIO address to be allocated can completely cover and allocate all the video memory addresses corresponding to the video memory space. At this time, it is allowed to build a static window mapping table based on the MMIO address to be allocated and the video memory address, so that the static window mapping table can be built stably.

[0076] Correspondingly, when the register space is smaller than the video memory space, it means that the MMIO address to be allocated cannot completely cover and be allocated to all the video memory addresses corresponding to the video memory space. In this case, if a static window mapping table is directly built based on the MMIO address to be allocated and the video memory address, it is easy for the same MMIO address to be allocated to two video memory addresses, thus forming an address conflict operation. In order to avoid the above situation, a dynamic window mapping table can be built based on the MMIO address to be allocated and the video memory address, and the construction of a static window mapping table based on the MMIO address to be allocated and the video memory address should be prohibited. This effectively ensures the stability and reliability of the construction of the static window mapping table.

[0077] In this embodiment, the management mode of the base address register is determined based on the data access request, and then the memory window mapping table corresponding to the second GPU is determined based on the management mode. This effectively ensures the accuracy and reliability of determining the memory window mapping table.

[0078] Figure 4 A flowchart illustrating the process of determining a dynamic window mapping table corresponding to a second GPU as a video memory window mapping table is provided as an exemplary embodiment of this application; based on the above embodiment, refer to the appendix. Figure 4 As shown, the memory window mapping table can be implemented not only as a static window mapping table but also as a dynamic window mapping table. In this case, determining the dynamic window mapping table corresponding to the second GPU as the memory window mapping table can include:

[0079] Step S401: Generate page fault information corresponding to the data access request.

[0080] When the memory window map is implemented as a dynamic window map, to ensure the timeliness and effectiveness of its construction, after receiving a data access request, it's necessary to check whether a dynamic window map needs to be built. For example, if a static window map for analyzing and processing the data access request does not exist, a dynamic window map needs to be built; if a static window map exists, a dynamic window map does not need to be built. When a dynamic window map needs to be built for a data access request, it indicates that the actual mapping relationship for implementing data access has not yet been established. In this case, a page fault exception message corresponding to the data access request can be generated, indicating that an abnormal access situation has occurred.

[0081] Step S402: Based on the page fault information, construct a dynamic window mapping table corresponding to the second GPU, wherein the dynamic window mapping table is the video memory window mapping table.

[0082] After obtaining page fault information, it can be directly analyzed and processed to construct a dynamic window mapping table corresponding to the second GPU. The mapping relationships included in this dynamic window mapping table can change or be adjusted dynamically. In some instances, the dynamic window mapping table can be determined based on a pre-trained mapping table construction model. In this case, constructing the dynamic window mapping table corresponding to the second GPU based on the page fault information can include: determining the pre-trained mapping table construction model; inputting the page fault information into the mapping table construction model for analysis and processing to obtain the dynamic window mapping table output by the mapping table construction model. This effectively ensures the accuracy and reliability of constructing the dynamic window mapping table.

[0083] In other instances, the dynamic window mapping table can be determined not only based on a pre-trained mapping table model, but also based on the temporary MMIO address allocated to the second GPU and the GPU's memory address. In this case, constructing the dynamic window mapping table corresponding to the second GPU based on page fault information can include: determining the temporary MMIO address allocated to the second GPU based on page fault information and data access requests, where the temporary MMIO address is a free address; and constructing the dynamic window mapping table corresponding to the second GPU based on the mapping relationship between the temporary MMIO address and the GPU's memory address. This also ensures the accuracy and reliability of constructing the dynamic window mapping table.

[0084] Furthermore, after generating page fault information corresponding to the data access request, since the page fault information is used to identify an abnormal access operation in the data processing access request, and the abnormal access operation may be related to a point-to-point access operation between the second GPU's memory, or the abnormal access operation may not be related to a point-to-point access operation between the second GPU's memory. Therefore, to avoid invalid creation of the dynamic window mapping table, detection can be performed based on whether the page fault information is related to the memory access operation of the second GPU, and the construction of the dynamic window mapping table corresponding to the second GPU can be determined based on different detection results. In this case, constructing the dynamic window mapping table corresponding to the second GPU based on the page fault information may also include: parsing the page fault information to obtain the request exception type corresponding to the data access request; and if the request exception type is used to identify that the page fault is related to the memory access operation of the second GPU, constructing the dynamic window mapping table corresponding to the second GPU based on the page fault information.

[0085] After obtaining page fault information, the information can be parsed to obtain the request exception type corresponding to the data access request. In some instances, the request exception type can be determined by analyzing the page fault information using a pre-trained parsing model. In this case, parsing the page fault information to obtain the request exception type corresponding to the data access request may include: determining the pre-trained parsing model; inputting the page fault information into the parsing model for analysis and processing; and obtaining the request exception type corresponding to the data access request output by the parsing model.

[0086] In other instances, the request exception type can also be determined by a preset type identifier. In this case, parsing the page fault information to obtain the request exception type corresponding to the data access request can include: using a preset calling function to analyze and process the data access request to obtain a preset type identifier corresponding to the data access request; and then determining the request exception type corresponding to the data access request based on the preset type identifier. This effectively ensures the accuracy and reliability of obtaining the request exception type.

[0087] The request exception types include a first type and a second type. The first type indicates that the page fault is related to the memory access operation of the second GPU, while the second type indicates that the page fault is unrelated to the memory access operation of the second GPU. For the dynamic window mapping table, since it is only related to the memory access operation of the second GPU, after obtaining the request exception type, it can be used to determine whether to construct the dynamic window mapping table. Specifically, if the request exception type indicates that the page fault is unrelated to the memory access operation of the second GPU, it means that the page fault information is caused by other abnormal operations. In this case, constructing a dynamic window mapping table corresponding to the second GPU cannot resolve the page fault situation, and therefore, constructing a dynamic window mapping table corresponding to the second GPU based on the page fault information can be prohibited. Correspondingly, when the request exception type is used to identify page faults related to the memory access operations of the second GPU, in order to alleviate or resolve the aforementioned page fault situation, a dynamic window mapping table corresponding to the second GPU is constructed based on the page fault information. This not only effectively allows for flexible selection of whether to construct a dynamic window mapping table based on different situations, but also improves the effective utilization rate of data processing resources to a certain extent.

[0088] Furthermore, when the memory window mapping table is implemented as a dynamic window mapping table corresponding to the second GPU, the access page table is also dynamically constructed based on the dynamic window mapping table. In this case, determining the access page table corresponding to the data access request may include: when the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, determining the temporary MMIO address corresponding to the memory address of the second GPU based on the dynamic window mapping table; and constructing the access page table based on the mapping relationship between the virtual address of the first GPU and the temporary MMIO address.

[0089] In the case where the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, the access page table can also be dynamically constructed based on temporary MMIO addresses. In this case, the temporary MMIO address corresponding to the memory address of the second GPU can be determined based on the dynamic window mapping table. Since the access page table includes the mapping relationship between MMIO addresses and the virtual address of the second GPU, in addition to determining the temporary MMIO address corresponding to the memory address of the second GPU, data access requests can also be analyzed and processed to determine the virtual address of the first GPU. Then, the access page table can be constructed based on the mapping relationship between the virtual address and the temporary MMIO address. The constructed access page table is a dynamic access page table. This effectively realizes that even when the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, the access page table for accessing the memory of the second GPU can also be dynamically constructed, thereby effectively ensuring the accuracy and reliability of the determination of the access page table.

[0090] In this embodiment, page fault information corresponding to data access requests is generated, and a dynamic window mapping table corresponding to the second GPU is constructed based on the page fault information. The dynamic window mapping table is then determined as the video memory window mapping table, which effectively ensures the accuracy and reliability of determining the video memory window mapping table.

[0091] For specific applications, please refer to the appendix. Figure 5 As shown, this application embodiment provides a method for enabling direct memory access between GPUs in a P2P (Peer-to-Peer) manner that does not support the native Peripheral Component Interconnect Express (PCIe) standard. The execution entity for this memory access method is a GPU-to-GPU memory access system. This system, through technical modifications to the driver layer, can provide direct end-to-end memory access capabilities for GPUs that do not support native PCIe P2P without the need for CPU intermediaries. Specifically, it can utilize a memory window mapping table, access page tables, and exception handling mechanisms to achieve direct memory access between GPUs. This not only improves the system performance of multi-GPU memory access operations but also reduces data transmission latency, making it suitable for distributed AI and high-performance computing scenarios. In some instances, the GPU-to-GPU memory access system may include a BAR1 mapping management module, a page fault handling module, and a page table management module, etc. These modules can be located in the driver layer. The GPU-to-GPU memory access method implemented based on the above-described system may include the following steps:

[0092] Step 1: When the GPU driver starts, determine the BAR1 interval allocated to GPU2.

[0093] When the GPU driver (used to drive one or more GPUs to perform data processing operations) starts, a preset module can be used to link the GPU driver to adjust the BAR1 interval allocated to GPU2. The BAR1 interval is the physical video memory window corresponding to GPU2. The BAR1 interval includes the memory-mapped input / output (MMIO) address used to implement video memory access operations between GPUs, so as to ensure full support for large-scale P2P communication access operations of multiple graphics cards.

[0094] Step 2: Obtain the data access request sent by GPU1. The data access request is used to access GPU2 and includes the virtual address of GPU1.

[0095] Users can trigger GPU1 to initiate a data access request for P2P access to GPU2 as needed, or they can use the AI ​​framework to trigger GPU1 to initiate a data access request for P2P access to GPU2.

[0096] Step 3: Determine the management mode corresponding to GPU1 based on the data access request, and determine the memory window mapping table and access page table corresponding to GPU2 based on the management mode.

[0097] After obtaining the data access request, the management mode identifier can be extracted from the request. Then, the management mode corresponding to GPU2 can be determined based on the management mode, which includes static mode and dynamic mode. After obtaining the management mode corresponding to GPU2, the corresponding memory window mapping table can be determined based on that management mode.

[0098] Specifically, in the static management mode, the pre-configured static window mapping table corresponding to GPU2 can be determined as the display window mapping table; in the dynamic management mode, the dynamic window mapping table corresponding to GPU2 can be determined as the display window mapping table.

[0099] For the display window mapping table, when the display window mapping table is a static window mapping table, the static window mapping table can be pre-created through the BAR1 mapping management module. In this case, in static mode, when the GPU driver is initialized, a complete static window mapping table from the local GPU to the remote peer memory can be uniformly established. At this time, all memory addresses corresponding to GPU2 will be pre-allocated to the MMIO addresses corresponding to the physical BAR1 window, thus completing the creation operation of the static window mapping table (including the mapping relationship between MMIO addresses and GPU2 memory addresses). The created static window mapping table is suitable for scenarios with performance priority and high bandwidth requirements.

[0100] Correspondingly, in dynamic mode, the BAR1 address is dynamically allocated to the GPU2 memory address only when the user program makes a data access request. After the data access request is received, since the display window mapping table has not been created in advance, the page fault handling module will generate page fault information for the first access operation of the data access request. Specifically, in dynamic mode, the page fault handling module can register exclusive error identification information according to the GPU2 driver and automatically parse the exception address information (including: access address, GPU device ID, type, etc.) to generate page fault information corresponding to the data access request.

[0101] After obtaining the page fault information, the BAR1 address can be dynamically allocated to the GPU2 memory address. The allocated BAR1 address is a temporarily free MMIO address. Then, the mapping relationship between the GPU2 memory address and the BAR1 address can be dynamically constructed, thereby obtaining a dynamic window mapping table. This can save the address resources corresponding to the BAR1 space to the maximum extent, which is conducive to improving the utilization of the mapping space.

[0102] Whether using a static or dynamic window mapping table, the BAR1 mapping management module can manage the utilization status of BAR1 addresses for each GPU2. Specifically, it can perform unique resource allocation, conflict detection, and release cleanup for BAR1 addresses, ensuring mapping consistency. Furthermore, in static mode, not only can a static window mapping table be pre-created, but the page table management module can also pre-create a static access page table, which includes the mapping relationship between MMIO addresses and virtual addresses in GPU1. In dynamic mode, the page table management module can also dynamically create access page tables, which can construct dynamic mapping relationships between virtual addresses and MMIO addresses for the local GPU1 as needed. Additionally, during the creation of access page tables, it supports creating mapping entries for a single page as well as creating mapping entries in batches across multiple pages, and is compatible with batch initialization and dynamically allocated application scenarios.

[0103] Furthermore, after obtaining the window mapping table and access page table, concurrent access operations of multiple processes can be performed based on the window mapping table and access page table. In the event that multiple GPUs fail simultaneously, locking and ordering operations can be performed on the window mapping table and access page table corresponding to each GPU, thus ensuring the consistency and accuracy of all mapping relationships.

[0104] Step 4: Access the GPU2 memory space based on the access page table and memory window mapping table.

[0105] After receiving a data access request, the virtual address corresponding to the data access request can be determined. Then, the GMMU (Memory Management Unit) in GPU1 can convert the virtual address of GPU1 into an MMIO address based on the access page table. GPU1 can then initiate an MMIO request to GPU2 based on the converted MMIO address. In response to the generated MMIO request, GPU2 can convert the MMIO address into the GPU2 memory address through the GMMU in GPU2. This enables GPU1 to directly access the GPU2 memory space through the GMMU.

[0106] Step 5: After accessing the memory space of the second GPU based on the access page table and the memory window mapping table, and assuming the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, determine the access status of the data access request; if the access status is complete, release the temporary MMIO address in the access page table and the temporary MMIO address in the dynamic window mapping table. This effectively enables dynamic management of the access page table and the dynamic window mapping table based on the status of the data access request, and automatically reclaims the corresponding mapping when it is no longer needed, thereby effectively ensuring the efficient utilization of data resources.

[0107] The technical solution provided in this application embodiment, in static mode, can utilize a pre-established static window mapping table and static access page table to implement P2P access operations between GPU memory; in dynamic mode, the generated page fault information triggers the dynamic establishment of a dynamic window mapping table and a dynamic access page table, and then P2P access operations between GPU memory can be implemented based on the dynamic window mapping table and access page table. Furthermore, after the data access operation is completed, the address resources corresponding to the dynamic window mapping table and dynamic access page table can be released. This achieves automatic, high-performance "on-demand allocation" of BAR1 address resources, and can greatly reduce BAR1 space waste and performance loss, thereby improving the effective utilization rate of address resources to a certain extent. Moreover, this solution can also achieve the following technical effects:

[0108] 1) No application modification is required, truly achieving universality. Specifically, all the P2P capability extensions between GPU memory implemented above are completed at the driver layer, maintaining complete transparency to the application layer. The user layer does not need to be aware of faults or modify code to achieve end-to-end P2P (point-to-point) access operations. Unlike the traditional approach that only provides user-space P2P libraries or interfaces, no additional adaptation code is required for all types of GPUs, significantly reducing the maintenance and usage threshold.

[0109] 2) Breaking through hardware limitations, it can dynamically allocate and expand BAR1 space for the GPU, breaking the dependence on the motherboard or chipset, and also supporting independent operation of the kernel module. This not only makes it easier to maintain the kernel module, but also significantly improves overall compatibility and future adaptability.

[0110] 3) Superior performance and reduced system overhead: Employing a unique hybrid static and dynamic BAR1 mapping strategy, combined with instant resource allocation triggered by page fault information, significantly improves the utilization of BAR1 physical space and reduces the space waste of traditional batch pre-allocation. Compared to user-space P2P solutions, it eliminates the CPU resource and time losses caused by multiple rounds of user-space-kernel-space switching, ensuring low end-to-end access latency. Furthermore, while maintaining system stability, it significantly improves the efficiency of direct data transfer between GPU memory, thereby enhancing the overall performance and resource utilization of multi-GPU systems and reducing the deployment cost of high-performance computing. Particularly in AI scenarios, direct GPU-to-GPU communication in training scenarios can significantly accelerate key operations such as gradient aggregation and parameter broadcasting, improving the scalability and convergence speed of large-scale distributed training, further enhancing the practicality of this solution.

[0111] Figure 6 A schematic diagram of a video memory access device provided for an exemplary embodiment of this application; see attached diagram. Figure 6 As shown, this embodiment provides a video memory access device, which is used to perform the above-described... Figure 2 The illustrated video memory access method, specifically, the video memory access device may include:

[0112] The first acquisition module 11 is used to acquire a data access request sent by the first graphics processing unit (GPU). The data access request is used to access the video memory space of the second GPU. The data access request includes the virtual address of the first GPU.

[0113] The first determining module 12 is used to determine the video memory window mapping table and the access page table based on the data access request. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address.

[0114] The first processing module 13 is used to access the memory space of the second GPU based on the access page table and the memory window mapping table.

[0115] The memory access device in this embodiment can also perform the above-described... Figures 1-5 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0116] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 11, 12, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0117] Figure 7 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application; as shown Figure 7 As shown, this embodiment provides an electronic device for performing the above-described... Figure 2 The illustrated video memory access method includes an electronic device that may include a memory 24 and a processor 25.

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

[0119] The processor 25, coupled to the memory 24, is used to execute a computer program in the memory 24 for: acquiring a data access request sent by the first graphics processing unit (GPU), the data access request being used to access the video memory space of the second GPU, the data access request including the virtual address of the first GPU; determining a video memory window mapping table and an access page table based on the data access request, the video memory window mapping table including the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU; the access page table including the mapping relationship between the virtual address of the first GPU and the MMIO address; and accessing the video memory space of the second GPU based on the access page table and the video memory window mapping table.

[0120] Regarding the processor 25 in this embodiment, it is also used to perform the above-described... Figures 1-5 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0121] Furthermore, such as Figure 7 As shown, the electronic device also includes other components such as a communication component 26, a display 27, a power supply component 28, and an audio component 29. Figure 7The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 7 The components shown. Additionally... Figure 7 The components within the center frame are optional, not mandatory, and their specific requirements depend on the product form of the workflow. The workflow in this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the workflow in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 7 The components within the center frame; if the working process of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, then it may not include... Figure 7 The component within the center frame.

[0122] Furthermore, such as Figure 7 As shown, the electronic device also includes other components such as a communication component 46, a display 47, a power supply component 48, and an audio component 49. Figure 7 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 7 The components shown. Additionally... Figure 7 The components within the center frame are optional, not mandatory, and their specific requirements depend on the product form of the workflow. The workflow in this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the workflow in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 7 The components within the center frame; if the working process of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, then it may not include... Figure 7 The component within the center frame.

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

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

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

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

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

[0128] Figure 8 A schematic diagram of a video memory access system provided for an exemplary embodiment of this application is shown in the attached diagram. Figure 8 As shown, this embodiment provides a video memory access system, including: a graphics processing unit (GPU) driver module 33 and multiple GPUs communicatively connected to the GPU driver module 33, including a first GPU 31 and a second GPU 32 among the multiple GPUs;

[0129] The first GPU 31 is used to send a data access request, which is used to access the second GPU 32. The data access request includes the virtual address of the second GPU 32.

[0130] The GPU driver module 33 is used to acquire data access requests, determine the video memory window mapping table and the access page table. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU 32. The access page table includes the mapping relationship between the MMIO address and the virtual address of the second GPU 32. Based on the access page table and the video memory window mapping table, the data access request is sent to the second GPU 32 to access the video memory space of the second GPU 32.

[0131] The GPU driver module 32 in this embodiment is also used to perform the above-mentioned... Figures 1-5 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0132] Accordingly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0133] Accordingly, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor is able to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0134] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0135] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for accessing video memory, characterized in that, include: Obtain a data access request sent by the first graphics processing unit (GPU), the data access request being used to access the video memory space of the second GPU, the data access request including the virtual address of the first GPU; Based on the data access request, a memory window mapping table and an access page table are determined. The memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the memory address of the second GPU. The memory window mapping table can be a static mapping table or a dynamic mapping table. The mapping relationship in the static window mapping table is fixed, while the mapping relationship in the dynamic window mapping table is dynamically variable. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address. The memory space of the second GPU is accessed based on the access page table and the memory window mapping table.

2. The method according to claim 1, characterized in that, Based on the data access request, the video memory window mapping table is determined, including: Based on the data access request, determine the management mode of the base address register; Based on the management mode, a memory window mapping table corresponding to the second GPU is determined.

3. The method according to claim 2, characterized in that, Based on the data access request, the management mode of the base address register is determined, including: Based on the data access request, a management mode identifier corresponding to the second GPU is determined; The management mode of the base address register is determined based on the management mode identifier.

4. The method according to claim 2, characterized in that, Based on the management mode, the memory window mapping table corresponding to the second GPU is determined, including: When the management mode is static mode, the static window mapping table corresponding to the second GPU is determined as the video memory window mapping table; When the management mode is dynamic mode, the dynamic window mapping table corresponding to the second GPU is determined as the video memory window mapping table.

5. The method according to claim 4, characterized in that, Before determining the static window mapping table corresponding to the second GPU as the video memory window mapping table, the method further includes: Determine the memory address of the second GPU and the MMIO address to be allocated in the base address register; Based on the MMIO address to be allocated and the video memory address, the static window mapping table is constructed.

6. The method according to claim 5, characterized in that, Based on the MMIO address to be allocated and the video memory address, the static window mapping table is constructed, including: Determine the register space of the base address register and the video memory space of the second GPU; If the register space is greater than or equal to the video memory space, the static window mapping table is constructed based on the MMIO address to be allocated and the video memory address.

7. The method according to claim 4, characterized in that, Determining the dynamic window mapping table corresponding to the second GPU as the video memory window mapping table includes: Generate page fault information corresponding to the data access request; Based on the page fault information, a dynamic window mapping table corresponding to the second GPU is constructed, and the dynamic window mapping table is the video memory window mapping table.

8. The method according to claim 7, characterized in that, Based on the page fault information, a dynamic window mapping table corresponding to the second GPU is constructed, including: The page fault information is parsed to obtain the request exception type corresponding to the data access request; When the requested exception type is used to identify that a page fault is related to the memory access operation of the second GPU, a dynamic window mapping table corresponding to the second GPU is constructed based on the page fault information.

9. The method according to claim 7, characterized in that, Based on the page fault information, a dynamic window mapping table corresponding to the second GPU is constructed, including: Based on the page fault information and the data access request, a temporary MMIO address allocated to the second GPU is determined, and the temporary MMIO address is a free address; Based on the mapping relationship between the temporary MMIO address and the memory address of the second GPU, a dynamic window mapping table corresponding to the second GPU is constructed.

10. The method according to any one of claims 1-9, characterized in that, Based on the data access request, the access page table is determined, including: When the memory window mapping table is a dynamic window mapping table corresponding to the second GPU, a temporary MMIO address corresponding to the memory address of the second GPU is determined based on the dynamic window mapping table. The access page table is constructed based on the mapping relationship between the virtual address of the first GPU and the temporary MMIO address.

11. The method according to any one of claims 1-9, characterized in that, After accessing the memory space of the second GPU based on the access page table and the memory window mapping table, the method further includes: If the video memory window mapping table is a dynamic window mapping table corresponding to the second GPU, determine the access status of the data access request; When the access status is complete, the temporary MMIO address in the access page table and the temporary MMIO address in the dynamic window mapping table are released.

12. A video memory access device, characterized in that, include: The first acquisition module is used to acquire a data access request sent by the first graphics processing unit (GPU), the data access request being used to access the video memory space of the second GPU, and the data access request including the virtual address of the first GPU. The first determining module is used to determine a video memory window mapping table and an access page table based on the data access request. The video memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the video memory address of the second GPU. The video memory window mapping table is either a static mapping table or a dynamic mapping table. The mapping relationship in the static window mapping table is fixed, while the mapping relationship in the dynamic window mapping table is dynamically variable. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address. The first processing module is used to access the memory space of the second GPU based on the access page table and the memory window mapping table.

13. A video memory access system, characterized in that, include: The graphics processing unit (GPU) driver module and multiple GPUs communicatively connected to the GPU driver module, wherein the multiple GPUs include a first GPU and a second GPU; The first GPU is used to send a data access request, the data access request being used to access the video memory space of the second GPU, and the data access request including the virtual address of the first GPU; The GPU driver module is used to acquire the data access request, determine the memory window mapping table and the access page table. The memory window mapping table includes the mapping relationship between the memory-mapped input / output (MMIO) address of the base address register and the memory address of the second GPU. The memory window mapping table can be a static mapping table or a dynamic mapping table. The mapping relationship in the static window mapping table is fixed, while the mapping relationship in the dynamic window mapping table is dynamically variable. The access page table includes the mapping relationship between the virtual address of the first GPU and the MMIO address. The second GPU's memory space is accessed based on the access page table and the memory window mapping table.

14. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the method of any one of claims 1-11.

15. A computer storage medium, characterized in that, Used to store a computer program that, when executed by a computer, implements the method of any one of claims 1-11.

16. A computer program product, characterized in that, include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the steps of the method of any one of claims 1-11.

Images