Virtual GPU migration method and device, equipment, medium and product

Abstract

The invention provides a virtual GPU migration method and device, equipment, a medium and a product, and relates to the technical field of cloud computing. The method comprises the steps of obtaining preset metadata corresponding to rendering data to be migrated in a system memory in response to a received instruction for calling a migration interface; and sending the preset metadata corresponding to the rendering data to be migrated to the target virtual machine, so that the target virtual machine reconstructs the rendering data based on the preset metadata corresponding to the rendering data to be migrated. According to the method, the memory page does not need to be tracked and marked, performance reduction of the virtual machine is avoided, and the use experience of a user is improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus, device, medium and product for migrating virtual GPUs. Background Technology

[0002] A Graphics Processing Unit (GPU) possesses graphics rendering, video decoding, and general computing capabilities. To enable virtual machines to have GPU capabilities, a virtualized GPU can be used to provide the virtual machine with capabilities similar to a physical graphics card. The driver submits rendering or computation commands, and the virtual GPU then parses these commands and calls the graphics card driver on the server to complete the rendering or computation.

[0003] In some cases, it may be necessary to migrate virtual machines running on one server to another. When migrating a virtual machine configured with a virtual GPU, the rendering context and rendering resources within the virtual GPU must also be migrated. To ensure a smooth migration, a common technique is dirty page tracing. This technique captures each rendering command sent to the physical GPU, identifies the corresponding physical memory page as dirty, and during migration, sends all dirty physical memory to the destination virtual machine over the network, thus completing the migration.

[0004] However, this migration method requires a lot of resources to track and identify memory pages during daily operation, which leads to a decrease in virtual machine performance and affects the user experience. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and product for migrating virtual GPUs, in order to solve the technical problem of virtual machine performance degradation and impact on user experience caused by virtual GPU migration.

[0006] In a first aspect, this application provides a method for migrating a virtual GPU, the method being applied to a source virtual machine, the method comprising:

[0007] In response to receiving an instruction to call the migration interface, the system retrieves the preset metadata corresponding to each rendering data to be migrated in the system memory;

[0008] The preset metadata corresponding to each of the rendering data to be migrated is sent to the target virtual machine, so that the target virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each of the rendering data to be migrated.

[0009] In one possible design, obtaining the preset metadata corresponding to each rendering data to be migrated in system memory includes:

[0010] Create multiple structures, each of which corresponds to a rendering data to be migrated;

[0011] Based on the structure, the corresponding preset metadata is obtained from each of the rendering data to be migrated.

[0012] In one possible design, each of the structures is pre-configured with metadata information of the rendering data to be extracted;

[0013] The step of obtaining corresponding preset metadata from each of the rendering data to be migrated based on the structure includes:

[0014] The preset metadata is extracted from each of the rendering data to be migrated located in the system memory according to the rendering data metadata information, so as to obtain the corresponding preset metadata from each of the rendering data to be migrated.

[0015] In one possible design, the rendering data includes rendering resources and a rendering context, and the method further includes:

[0016] Acquire at least one rendering resource located in the physical graphics processor (GPU) and save the at least one rendering resource to the system memory;

[0017] Send the at least one rendering resource to the destination virtual machine.

[0018] In one possible design, saving the at least one rendering resource to the system memory includes:

[0019] Determine the data dimensions of the at least one rendering resource, and determine the corresponding API based on the data dimensions;

[0020] Call the corresponding API to store at least one rendering resource into the system memory.

[0021] In one possible design, before obtaining the preset metadata corresponding to each rendering data to be migrated in system memory, the method further includes:

[0022] In response to receiving an instruction to call the migration interface, the migration thread is set to the state where rendering data reading has begun;

[0023] The step of obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory includes:

[0024] In response to the rendering thread determining that the current state is the start of reading rendering data, the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory.

[0025] In one possible design, before the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory, the method further includes:

[0026] The rendering thread is used to determine whether the current state is the state where rendering data reading has begun;

[0027] If not, the rendering thread will continue processing the rendering instructions.

[0028] In one possible design, after the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory, the method further includes:

[0029] The rendering thread is set to the state where rendering data has been read.

[0030] In one possible design, sending the preset metadata corresponding to each of the rendering data to be migrated to the destination virtual machine includes:

[0031] In response to determining that the current state is "rendering data reading complete" using the migration thread, the migration thread sends the preset metadata corresponding to each render data to be migrated to the destination virtual machine.

[0032] In one possible design, after setting the migration thread to the state where rendering data reading has begun, the method further includes:

[0033] The migration thread is used to determine whether the current state is a state where rendering data reading is complete;

[0034] If not, the process of determining whether the current state is "rendering data reading completed" using the migration thread will continue after a first preset time interval.

[0035] In one possible design, after the migration thread sends the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, the method further includes:

[0036] Set the migration thread to an idle state;

[0037] In response to the rendering thread determining that the current state is idle, the rendering thread is shut down.

[0038] In one possible design, after setting the rendering thread to the state where rendering data reading is complete, the method further includes:

[0039] The rendering thread is used to determine whether the current state is idle.

[0040] If not, the step of determining whether the current state is idle using the rendering thread will continue after a second preset time interval.

[0041] Secondly, this application provides a method for migrating a virtual GPU, the method being applied to a target virtual machine, the method comprising:

[0042] Receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine;

[0043] The rendering data is reconstructed based on the preset metadata corresponding to each of the rendering data to be migrated.

[0044] In one possible design, the structure further includes: receiving at least one rendering resource located in the physical graphics processing unit (GPU) sent by the source virtual machine;

[0045] Reconstructing rendering data based on at least one of the rendering resources.

[0046] In one possible design, the method further includes:

[0047] In response to the start of receiving preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the migration thread is set to the rendering data writing state.

[0048] In one possible design, after receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the method further includes:

[0049] Set the migration thread to the state where rendering data writing is complete.

[0050] In one possible design, before reconstructing the rendering data based on the preset metadata corresponding to each of the rendering data to be migrated, the method further includes:

[0051] The rendering thread is used to determine whether the current state is the end state of the rendering data writing;

[0052] The reconstruction of rendering data is performed based on the preset metadata corresponding to each rendering data to be migrated, including:

[0053] In response to the rendering thread determining that the current state is the end state of the rendering data writing, the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0054] In one possible design, before the rendering thread reconstructs the rendering data based on preset metadata corresponding to each rendering data to be migrated, the method further includes:

[0055] The rendering thread is used to determine whether the current state is the end state of the rendering data writing;

[0056] If not, the rendering thread continues to process the rendering instructions.

[0057] In one possible design, after the rendering thread reconstructs the rendering data based on preset metadata corresponding to each rendering data to be migrated, the method further includes:

[0058] The rendering thread is set to an idle state, and the rendering thread continues to process rendering instructions.

[0059] Thirdly, this application provides a virtual GPU migration apparatus, the apparatus being located in a source virtual machine, the apparatus comprising:

[0060] The acquisition module is used to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory in response to the instruction to call the migration interface.

[0061] The sending module is used to send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, so that the destination virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0062] Fourthly, this application provides a virtual GPU migration apparatus, the apparatus being located in a target virtual machine, the apparatus comprising:

[0063] The receiving module is used to receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine;

[0064] The reconstruction module is used to reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0065] Fifthly, this application provides a virtual GPU migration device, the device comprising: a processor, and a memory and a transceiver communicatively connected to the processor;

[0066] The memory stores computer-executed instructions; the transceiver is used for sending and receiving data.

[0067] The processor executes computer execution instructions stored in the memory to implement the method as described in any of the first aspects.

[0068] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first or second aspects above.

[0069] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first or second aspects above.

[0070] The virtual GPU migration method, apparatus, device, medium, and product provided in this application, in response to receiving an instruction to call the migration interface, obtains preset metadata corresponding to each rendering data to be migrated in the system memory; sends the preset metadata corresponding to each rendering data to be migrated to the target virtual machine, so that the target virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated. Upon receiving the instruction to call the migration interface, obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory eliminates the need to store memory pages containing all the data; only the metadata of each rendering data needs to be migrated, saving resource consumption, avoiding performance degradation of the virtual machine, and improving the user experience when using the virtual machine. Then, sending the preset metadata to the target virtual machine allows the target virtual machine to reconstruct the rendering data based on the preset metadata of each rendering data, thus completing the virtual GPU migration. This achieves real-time migration without the user's awareness and ensures that the target virtual machine can complete the reconstruction based on the metadata. Since the execution entity of the virtual GPU migration method provided in this application is located at the application layer of the virtual machine, and is independent of the graphics card driver and graphics card type, this method is more universal. Attached Figure Description

[0071] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0072] Figure 1 An application scenario diagram of the virtual GPU migration method provided in an embodiment of this application;

[0073] Figure 2 A server architecture diagram including virtual machines provided for an embodiment of this application;

[0074] Figure 3 A flowchart illustrating a virtual GPU migration method provided in an embodiment of this application;

[0075] Figure 4 A schematic diagram illustrating the process by which a source virtual machine, as provided in an embodiment of this application, stores rendering resources located on a physical GPU into a structure.

[0076] Figure 5 A schematic diagram illustrating the process of reconstructing rendering resources located on a physical GPU for a target virtual machine, as provided in an embodiment of this application;

[0077] Figure 6A flowchart illustrating a virtual GPU migration method provided in another embodiment of this application;

[0078] Figure 7 A flowchart illustrating the migration process of the migration thread and rendering thread located in the source virtual machine during migration, provided as an embodiment of this application;

[0079] Figure 8 A flowchart illustrating the migration and rendering threads of the destination virtual machine during migration, provided as an embodiment of this application;

[0080] Figure 9 A signaling interaction flowchart of a virtual GPU migration method provided in an embodiment of this application;

[0081] Figure 10 A schematic diagram of the structure of a virtual GPU migration device provided in an embodiment of this application;

[0082] Figure 11 A schematic diagram of the structure of a virtual GPU migration device provided in another embodiment of this application;

[0083] Figure 12 This is a schematic diagram of the structure of a virtual GPU migration device provided in an embodiment of this application.

[0084] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0085] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0086] It should be noted that certain software, components, and models may be mentioned in the embodiments of this application. These should be considered as exemplary and are intended only to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0087] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0088] In some cases, it may be necessary to migrate virtual machines running on one server to another. If the virtual machine is configured with a virtual GPU, the rendering data within the virtual GPU needs to be migrated during the migration process. Currently, dirty page tracing is commonly used to achieve virtual GPU migration. This involves developing a separate graphics proxy library that can interact with the GPU driver running inside the virtual machine. During the virtual machine's daily operation, it captures every rendering command sent to the physical GPU, parses and translates it, and tracks the write actions of each rendering command to the memory where the graphics proxy library resides. The corresponding physical memory pages are identified as dirty. During migration, all dirty physical memory pages are sent to the destination virtual machine over the network. Upon receiving these dirty physical pages, the destination virtual machine updates them in system memory. However, using this method for virtual GPU migration not only requires developing a separate graphics proxy library for each virtual machine, but also consumes significant resources during daily operation to track and identify memory pages, leading to virtual machine performance degradation and impacting the user experience.

[0089] Therefore, when facing technical issues in existing technologies, to avoid impacting the performance of the virtual machine during daily operation, the preset metadata corresponding to each rendering data to be migrated in the system memory is only retrieved when a migration interface call instruction is received. This eliminates the need to track memory pages during daily operation, preventing resource consumption that could reduce virtual machine performance and improve the user experience. Furthermore, to further reduce resource consumption and increase migration speed, only the preset metadata needs to be sent to the destination virtual machine during migration, instead of sending all memory pages, reducing the amount of data to be migrated. The destination virtual machine can also reconstruct the rendering data based on the preset metadata corresponding to the rendering data in each structure, further reducing resource consumption and accelerating the migration speed.

[0090] Figure 1 This is an application scenario diagram of the virtual GPU migration method provided in an embodiment of this application, such as... Figure 1 As shown in the figure, the application scenario diagram of the virtual GPU migration method provided in this embodiment includes: server 101, source virtual machine 102, server 103 and destination virtual machine 104.

[0091] It is understandable that when migrating from virtual machine A to virtual machine B, virtual machine A is called the source virtual machine and virtual machine B is called the destination virtual machine; conversely, when migrating from virtual machine B to virtual machine A, virtual machine B is called the source virtual machine and virtual machine A is called the destination virtual machine.

[0092] For example, in this application scenario, the preset metadata migration is performed by creating a structure. Migration can also be performed in other ways, and this embodiment does not limit this method.

[0093] Specifically, after receiving the instruction to call the migration interface, the source virtual machine 102 located in server 101 creates multiple structures, each corresponding to a rendering data to be migrated; it stores the preset metadata corresponding to each rendering data in system memory into the corresponding structure; and sends each structure to the destination virtual machine 104. The destination virtual machine 104 located in server 103 receives the multiple structures sent by the source virtual machine, each structure storing the preset metadata corresponding to each rendering data to be migrated in system memory; and then reconstructs the rendering data based on the preset metadata corresponding to the rendering data in each structure.

[0094] Optionally, the virtual GPU migration method provided in this application can also be used for virtual GPU migration between two virtual machines located on the same server, but this embodiment does not limit this.

[0095] For example, such as Figure 2 As shown, server 20 includes virtual machine A 201, virtual machine B 202, operating system 203, physical GPU 204, central processing unit (CPU) 205, and memory 206. Virtual machine A 201 includes: application APP 201a, virtual GPU driver 201b, virtual GPU 201c, and rendering backend 201d. Virtual machine B 202 includes: application APP 202a, virtual GPU driver 202b, virtual GPU 202c, and rendering backend 202d.

[0096] It should be noted that the virtual GPU driver, virtual GPU, and rendering backend included in Virtual Machine A 201 and Virtual Machine B 202 have the same functions. The virtual GPU driver is the driver for the virtual GPU, responsible for handling rendering tasks / computation / video encoding / decoding requests from the client application layer, converting and encapsulating the application layer commands, and sending them to the virtual GPU. The virtual GPU parses the commands from the virtual GPU driver; most of its rendering tasks are handled by the rendering backend, and the virtual GPU is also responsible for displaying the rendering results. The rendering backend parses the rendering commands issued by the virtual GPU driver, converts them into rendering task requests that the server operating system can recognize, and sends them to the physical graphics card driver on the server. It also includes the creation and management of rendering resources. The physical GPU executes the commands issued by the rendering backend, including rendering tasks, computation tasks, audio and video encoding / decoding tasks, and the creation and management of rendering resources.

[0097] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0098] Figure 3 A flowchart of a virtual GPU migration method provided in one embodiment of this application is shown below. Figure 3 As shown, the execution entity in this embodiment is a virtual GPU migration device. This virtual GPU migration device resides in the source virtual machine and can be implemented through a computer program, a medium storing the relevant computer program (such as a USB flash drive and / or optical disc), or integrated into a virtual GPU migration device. The virtual GPU migration method provided in this embodiment includes the following steps:

[0099] Step 301: In response to receiving the instruction to call the migration interface, obtain the preset metadata corresponding to each rendering data to be migrated in the system memory.

[0100] The rendering data may include rendering resources and rendering context.

[0101] Metadata refers to the descriptive information of the rendering data. Preset metadata refers to the metadata that needs to be migrated in advance. The metadata of the rendering context can be the configuration parameters of each state of the rendering pipeline, etc. The metadata of the rendering resources can be the data dimensions, the correspondence with a certain state in the rendering pipeline, the data format, the length / width / depth, and the sampling information, etc.

[0102] Understandably, a virtual machine needs to migrate multiple virtual devices during the migration process. When the migration of a virtual GPU begins, the source virtual machine will call the migration interface located in the rendering backend to start the migration of the virtual GPU.

[0103] It should be noted that each application in the virtual machine corresponds to a rendering context. A rendering context can contain various states of the rendering pipeline. Some of these states may correspond to rendering resources, such as the vertex shader state corresponding to the vertex data in the rendering resources, and the sampler state corresponding to the texture data in the rendering resources.

[0104] Specifically, when the virtual GPU migration device receives an instruction to call the migration interface, the virtual GPU migration device traverses all rendering data located in system memory and obtains the preset metadata corresponding to each rendering data.

[0105] Optionally, the type information of preset metadata can be pre-configured in the virtual GPU migration device, and the preset metadata can be extracted from each rendering data based on the type information; alternatively, a structure can be created, and the metadata information that can be stored in the structure can be pre-defined when the structure is defined, and each created structure contains the same metadata information. The virtual GPU migration device can extract the preset metadata from each rendering data and store it in the corresponding structure by obtaining the metadata information in the structure; or other methods can be used to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory. This embodiment does not limit this method.

[0106] The various states of the rendering pipeline can include: vertex element, vertex buffer object, index buffer object, shader, constant, constant buffer, shader view, sampler state, color surface, depth surface, viewport, scissor state, depth stencil state, blend state, rasterization state, clipping state, outflow, image view, shader storage buffer object, and atomic buffer object.

[0107] Vertex elements define the components of vertex data, such as position, normals, color, or texture coordinates; vertex buffer objects store vertex data in the physical GPU's memory, enabling efficient processing by the physical GPU; index buffer objects store vertex indices, allowing vertex data reuse, thus reducing redundancy and improving rendering efficiency; shaders are programs running on the physical GPU used to compute various stages of graphics (such as vertex shaders and fragment shaders); constants are constant values ​​used in shaders that do not change during shader execution; constant buffers store shader constants and are used to transfer data from the CPU to the physical GPU shaders; shader views define how shaders can access textures or other resources; sampler states define how textures are sampled in the shader, such as filtering methods and addressing modes; color surfaces are the rendering target surfaces used to store rendered color data; depth surfaces, also called depth buffers. The shader uses the following settings: Z-buffer (for storing depth information for depth testing); viewport (defining the final image area to be rendered, i.e., the area projected onto the window); scissors state (defining the screen-space clipping rectangle to limit the rendering area); depth stencil state (defining the behavior of depth and stencil testing, including how depth values ​​are handled); blending state (defining color blending methods, such as transparency blending); rasterization state (defining how geometry is converted to pixels, including face culling, fill mode, etc.); clipping state (defining spatial clipping behavior, typically used in view projection); flowout (outputting vertex data during the geometry shader stage for later use or processing); image view (defining how the image is accessed in the shader); shader storage buffer object (a physical GPU memory buffer that allows reading and writing large amounts of data in the shader); and atomic buffer object (a buffer object used to perform atomic operations in the shader, ensuring safe concurrent access to data across multiple threads).

[0108] Optionally, as the functionality of the virtual GPU improves, the rendering data can also include audio and video decoding resources, computing resources, and ray tracing resources.

[0109] Step 302: Send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine so that the destination virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0110] In this context, the destination virtual machine refers to the virtual machine that receives migration data sent from other virtual machines. For example, when migrating from virtual machine A to virtual machine B, virtual machine A is called the source virtual machine, and virtual machine B is called the destination virtual machine.

[0111] Specifically, after obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory, the preset metadata corresponding to each rendering data to be migrated is sent to the target virtual machine through the same interface, so that the target virtual machine can reconstruct the rendering data based on the preset metadata corresponding to the rendering data in each structure.

[0112] The virtual GPU migration method provided in this application, in response to receiving an instruction to call the migration interface, obtains the preset metadata corresponding to each rendering data to be migrated in the system memory; and sends the preset metadata corresponding to each rendering data to be migrated to the target virtual machine, so that the target virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated. Upon receiving the instruction to call the migration interface, obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory eliminates the need to store memory pages containing all the data; only the metadata of each rendering data needs to be migrated, which not only saves resource consumption but also avoids performance degradation of the virtual machine, improving the user experience when using the virtual machine. Then, the preset metadata is sent to the target virtual machine, so that the target virtual machine can reconstruct the rendering data based on the preset metadata of each rendering data, thus completing the virtual GPU migration. This achieves real-time migration without the user's awareness and ensures that the target virtual machine can complete the reconstruction based on the metadata. Since the execution entity of the virtual GPU migration method provided in this application is located at the application layer of the virtual machine and is independent of the graphics card driver and graphics card type, this method is more universal.

[0113] As an optional implementation, based on the above embodiments, preset metadata corresponding to each rendering data to be migrated in the system memory is obtained, including:

[0114] Create multiple structures, each corresponding to a different piece of rendering data to be migrated;

[0115] Based on the structure, the corresponding preset metadata is obtained from each rendering data to be migrated.

[0116] Among them, a structure is a composite data type that can define the type or structure of the data items to be stored. Related data can be organized together in a structure, making it easier to manage and operate.

[0117] Specifically, when the virtual GPU migration device receives an instruction to call the migration interface, it creates multiple structures in the system memory. The number of structures is the same as the total number of rendering resources and rendering contexts in the rendering data. Each structure corresponds to a rendering resource or a rendering context, and different structures correspond to different rendering resources and rendering contexts. After the structures are created, the virtual GPU migration device traverses all rendering resources and rendering contexts in the system memory and stores the preset metadata corresponding to each rendering resource and rendering context into the corresponding structure.

[0118] The virtual GPU migration method provided in this application obtains preset metadata corresponding to each rendering data to be migrated in system memory, including: creating multiple structures, wherein each structure corresponds to each rendering data to be migrated; and obtaining the corresponding preset metadata from each rendering data to be migrated based on the structure. By creating structures, each rendering data to be migrated has a corresponding structure, ensuring orderliness during the migration process; and storing the preset metadata corresponding to each rendering data in system memory into the corresponding structure, it is not necessary to store memory pages containing all the data, but only to store the metadata of each rendering data into the corresponding structure for migration. This not only saves resource consumption but also avoids performance degradation of the virtual machine and improves the user experience when using the virtual machine.

[0119] As an optional implementation, based on the above embodiments, each structure is pre-configured with rendering data metadata information to be extracted;

[0120] Based on the structure, the corresponding preset metadata is obtained from each rendering data to be migrated, including:

[0121] Based on the rendering data metadata information, preset metadata is extracted from each rendering data to be migrated located in the system memory, so as to obtain the corresponding preset metadata from each rendering data to be migrated.

[0122] Among them, rendering data metadata information refers to the information used to instruct the virtual GPU migration device to extract preset metadata for each rendering resource and rendering context, such as the type name and memory address of the rendering resource metadata, and the state information contained in the rendering context.

[0123] Specifically, when defining a structure, the rendering data metadata information to be extracted can be pre-configured in the structure. Therefore, each created structure contains rendering data metadata information. After the structure is created, the virtual GPU migration device parses the structure, obtains the rendering data metadata information from the structure, locates the specific rendering resource or rendering context in the system memory based on the rendering data metadata information, queries the rendering resource or rendering context based on the metadata information, and extracts the metadata related to the rendering data metadata information from each rendering resource and rendering context as preset metadata.

[0124] The virtual GPU migration method provided in this application includes pre-configuring rendering data metadata information to be extracted in each structure. Obtaining corresponding preset metadata from each rendering data to be migrated based on the structure includes: extracting preset metadata from each rendering data to be migrated located in system memory according to the rendering data metadata information, thereby obtaining the corresponding preset metadata from each rendering data to be migrated. By pre-configuring the rendering data metadata information to be extracted in each structure, extraction can be performed based on this rendering data metadata information during migration, improving migration efficiency. The preset metadata extracted from the rendering data metadata information is important data in each rendering resource and rendering context, realizing abstract management of rendering resources and rendering context.

[0125] As an optional implementation, based on the above embodiments, the rendering data includes rendering resources and a rendering context, and the method further includes:

[0126] Acquire at least one rendering resource located in the physical graphics processor (GPU) and save at least one rendering resource to system memory;

[0127] Send at least one rendering resource to the destination virtual machine.

[0128] It is understandable that some of the various rendering resources may also be stored in the physical GPU's video memory. Therefore, when migrating, the rendering resources stored in the physical GPU also need to be migrated.

[0129] Specifically, the virtual GPU migration device traverses the rendering resources located on the physical GPU and obtains at least one rendering resource. Since different types of rendering resources need to be migrated through different APIs, after obtaining the rendering resources, the corresponding API is called to migrate each rendering resource.

[0130] For example, such as Figure 4 As shown, when migrating rendering resource A, the preset metadata corresponding to rendering resource A located in memory 401a of system 401 can be stored first into the corresponding structure in memory 401a of system 401. Then, the video memory 402a of physical GPU 402 is traversed to check if there are any resources in rendering resource A. If so, the corresponding API is called to store the resources in video memory 402a of physical GPU 402 in rendering resource A into the corresponding structure in memory 401a of system 401 through bus interface standard 403.

[0131] Alternatively, the preset metadata corresponding to various rendering resources located in the system memory can be stored in the corresponding structure, and then the physical GPU can be traversed to obtain the rendering resources therein, and the corresponding API can be called to store them in the corresponding structure. This embodiment does not limit this.

[0132] Accordingly, after receiving the preset metadata, the target virtual machine will reconstruct resources based on the rendering resources, such as... Figure 5 As shown, after receiving each structure, the target virtual machine stores it in the memory 501a of the system 501, and then calls the corresponding API to update the rendering resources located in the physical GPU in the source virtual machine to the video memory 502a located in the physical GPU 502 through the bus interface standard 503.

[0133] The virtual GPU migration method provided in this application includes rendering data such as rendering resources and rendering context. The method further includes: acquiring at least one rendering resource located in the physical graphics processing unit (GPU) and saving the at least one rendering resource to system memory; and sending the at least one rendering resource to the destination virtual machine. Since some rendering resources are stored in the physical GPU, acquiring and storing at least one rendering resource located in the physical GPU ensures that no rendering resources are lost during the migration process. Calling the corresponding application programming interface (API) to migrate each rendering resource enables effective migration of rendering resources located on the physical GPU.

[0134] As an optional implementation, based on the above embodiments, at least one rendering resource is saved to system memory, including:

[0135] Identify at least one data dimension for a rendering resource, and determine the corresponding API based on the data dimension;

[0136] Call the corresponding API to store at least one rendering resource into system memory.

[0137] It is understandable that rendering resources can be data of different dimensions, such as one-dimensional data and multi-dimensional data. Multi-dimensional data includes two-dimensional data, three-dimensional data, etc.

[0138] Specifically, after obtaining at least one rendering resource located in the physical GPU, the data dimension information of the rendering resource is found from the extracted rendering resource metadata. Based on the found data dimension, the corresponding API is found, and the corresponding API is called to store the rendering resource of the corresponding dimension into the system memory.

[0139] Optionally, the APIs corresponding to each data dimension can be pre-configured in the virtual GPU migration device so that the corresponding APIs can be quickly determined after the data dimensions are determined; or other methods can be used to determine the corresponding APIs, which is not limited in this embodiment.

[0140] For example, for one-dimensional data in the rendering resource, the corresponding CPU pointer can be obtained through glMapBufferRange, and then memcpy can be called to store the data in system memory; for two-dimensional / multi-dimensional data in the rendering resource, glReadPixels or glGetTexImage can be called to store the data in system memory.

[0141] It should be noted that glMapBufferRange, glReadPixels, and glGetTexImage are all APIs defined by the cross-platform graphics interface (Open Graphics Library, OpenGL).

[0142] Accordingly, when the target virtual machine receives the preset metadata and performs resource reconstruction, for one-dimensional rendering resources, glBufferSubData can be called to update the data to the physical GPU; for two-dimensional / multi-dimensional rendering resources, glTexImage can be called to update the data to the physical GPU.

[0143] It should be noted that glBufferSubData and glTexImage are both APIs defined by OpenGL.

[0144] The virtual GPU migration method provided in this application saves at least one rendering resource to system memory, including: determining the data dimensions of at least one rendering resource, and determining the corresponding API based on the data dimensions; and calling the corresponding API to store at least one rendering resource in system memory. By determining the data dimensions of the rendering resource to determine the corresponding API, and calling the corresponding API to store the data of the corresponding dimension in system memory, it is possible to ensure that data of each dimension can be successfully migrated, preventing errors during the migration process that could lead to migration failure.

[0145] As an optional implementation, based on the above embodiments, before obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory, the method further includes:

[0146] In response to receiving an instruction to call the migration interface, the migration thread is set to the state where rendering data reading has begun;

[0147] Retrieve the preset metadata corresponding to each rendering data to be migrated in the system memory, including:

[0148] In response to the rendering thread determining that the current state is the start of reading rendering data, the rendering thread retrieves the preset metadata corresponding to each rendering data to be migrated in the system memory.

[0149] Specifically, when migrating virtual machines, multiple virtual devices need to be migrated. When migrating virtual GPUs begins, the migration thread updates the current state to the state where rendering data has started reading. When the rendering thread detects that the current state is the state where rendering data has started reading, it begins to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory.

[0150] The virtual GPU migration method provided in this application, before obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory, further includes: in response to receiving an instruction to call the migration interface, setting the migration thread to a rendering data start reading state; obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory includes: in response to the rendering thread determining that the current state is a rendering data start reading state, using the rendering thread to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory. Using the migration thread to update the current state to the rendering data start reading state allows the rendering thread to promptly know that the current state is in the rendering data start reading state. When the rendering thread determines that the current state is the rendering data start reading state, it then begins to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory. This ensures the orderly operation of the migration thread and the rendering thread during the migration process, avoiding conflicts between the two threads that could lead to rendering data corruption.

[0151] As an optional implementation, based on the above embodiments, before using a rendering thread to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory, the method further includes:

[0152] The rendering thread is used to determine whether the current state is the state where rendering data reading has begun.

[0153] If not, the rendering thread will continue processing the rendering instructions.

[0154] Specifically, the rendering thread periodically checks whether the current state is the state where rendering data has started to be read. If the result is that the current state is the state where rendering data has started to be read, then it starts to store the rendering data that needs to be migrated in the system memory, extract the preset metadata, and save the rendering resources that need to be migrated on the physical GPU to the system memory. If the result is that the current state is not the state where rendering data has started to be read, then the rendering thread will continue to process the rendering instructions.

[0155] The virtual GPU migration method provided in this application embodiment, before the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory, further includes: using the rendering thread to determine whether the current state is the rendering data start reading state; if not, the rendering thread continues to process rendering instructions. By using the rendering thread to determine whether the current state is the rendering data start reading state, the latest state can be obtained in a timely manner so that the next action can be taken based on the latest state. If the current state is not the rendering data start reading state, then the rendering thread continues to process rendering instructions, which can both obtain the latest state in a timely manner and not affect the daily work of the rendering thread.

[0156] As an optional implementation, based on the above embodiments, after obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory using a rendering thread, the method further includes:

[0157] Set the rendering thread to the state where rendering data has been read.

[0158] Specifically, after the rendering thread has stored all the rendering data that needs to be migrated, it will update the current state from the state where rendering data reading has started to the state where rendering data reading has been completed.

[0159] The virtual GPU migration method provided in this application embodiment, after the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory, further includes: setting the rendering thread to a state where rendering data reading is complete. The rendering thread promptly updates the rendering data reading start state to the rendering data reading complete state to ensure proper synchronization with the migration thread and guarantee the smooth migration of the virtual GPU.

[0160] As an optional implementation, based on the above embodiments, the preset metadata corresponding to each rendering data to be migrated is sent to the destination virtual machine, including:

[0161] In response to the migration thread determining that the current state is the rendering data reading completion state, the migration thread sends the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine.

[0162] Specifically, after the migration thread updates the current state to the state where rendering data has started reading, it will continuously monitor the changes in the current state until the migration thread determines that the current state is the state where rendering data has been read. Then, it will send the preset metadata to the destination virtual machine.

[0163] The virtual GPU migration method provided in this application sends preset metadata corresponding to each piece of rendering data to be migrated to the destination virtual machine. The method includes: in response to a migration thread determining that the current state is a rendering data reading completion state, the migration thread sends the preset metadata corresponding to each piece of rendering data to be migrated to the destination virtual machine. The migration thread determines whether to send the preset metadata to the destination virtual machine by determining the current state, ensuring the integrity of the sent preset metadata and preventing resource loss that could occur if the migration thread starts migrating before the rendering thread has finished storing all rendering data.

[0164] As an optional implementation, based on the above embodiments, after setting the migration thread to the state where rendering data reading has begun, the method further includes:

[0165] A migration thread is used to determine whether the current state is one where rendering data reading is complete.

[0166] If not, the process of using a migration thread to determine whether the current state is "rendering data read complete" will continue after a first preset time interval.

[0167] The first preset duration refers to the time interval pre-configured in the migration thread when determining whether the current state is the state where the rendering data has been read. For example, 100 milliseconds. It can be configured as needed, and this embodiment does not limit it.

[0168] Specifically, after the migration thread updates the current state to the state where rendering data has started reading, it will determine whether the current state is the state where rendering data has been read completely every first preset time interval. If the result is yes, then the preset metadata is sent to the destination virtual machine; if the result is no, then the migration thread will determine whether the current state is the state where rendering data has been read completely again after the first preset time interval.

[0169] The virtual GPU migration method provided in this application, after setting the migration thread to the state where rendering data reading has begun, further includes: using the migration thread to determine whether the current state is the state where rendering data reading is complete; if not, then continuing to execute the step of using the migration thread to determine whether the current state is the state where rendering data reading is complete after a first preset time interval. By presetting the first time interval, the migration thread can be promptly aware of changes in the current state. If the current state is not the state where rendering data reading is complete, then continuing to determine after the first preset time interval ensures the orderly operation of the migration thread.

[0170] As an optional implementation, based on the above embodiments, after the migration thread sends the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, the method further includes:

[0171] Set the migration thread to an idle state;

[0172] In response to the rendering thread determining that the current state is idle, the rendering thread is shut down.

[0173] Specifically, after the migration thread sends each structure to the destination virtual machine, it updates the current state from the rendering data read-complete state to the idle state. Once the rendering thread determines that the current state is idle, it can shut down the rendering thread.

[0174] The virtual GPU migration method provided in this application includes, after the migration thread sends the preset metadata corresponding to each rendering data to be migrated to the target virtual machine, the method further includes: setting the migration thread to an idle state; and shutting down the rendering thread in response to the rendering thread determining that the current state is idle. The migration thread updates its state to idle after the rendering data has been read, which allows the rendering thread to promptly know the current state to take the next step, and also allows the migration thread to continue migrating other virtual devices based on the current state, improving the efficiency of virtual machine migration. Since the rendering thread no longer needs to work after the rendering data migration is completed, it is shut down when the rendering thread determines that the current state is idle.

[0175] As an optional implementation, based on the above embodiments, after setting the rendering thread to the state where rendering data has been read, the method further includes:

[0176] The rendering thread is used to determine whether the current state is idle.

[0177] If not, the process of determining whether the current state is idle will continue after a second preset interval.

[0178] The second preset duration refers to the time interval pre-configured in the rendering thread when determining whether the current state is idle, such as 50 milliseconds. It can be configured as needed, and this embodiment does not limit it.

[0179] Specifically, after the rendering thread updates its current state to "rendering data read complete", it checks whether the current state is idle every second preset time interval. If the result is yes, the rendering thread is closed; if the result is no, the rendering thread checks whether the current state is idle again after the second preset time interval.

[0180] The virtual GPU migration method provided in this application, after setting the rendering thread to a state where rendering data reading is complete, further includes: using the rendering thread to determine whether the current state is idle; if not, then continuing to execute the step of using the rendering thread to determine whether the current state is idle after a second preset time interval. By presetting the second time interval, the rendering thread can be promptly aware of changes in the current state. If the current state is not idle, the determination is continued after the second preset time interval, ensuring the orderly operation of the rendering thread.

[0181] Figure 6 A flowchart of a virtual GPU migration method provided in another embodiment of this application is shown below. Figure 6 As shown, the execution entity in this embodiment is a virtual GPU migration device. This virtual GPU migration device resides in the target virtual machine and can be implemented through a computer program, a medium storing the relevant computer program (such as a USB flash drive and / or optical disc), or integrated into a virtual GPU migration device. The virtual GPU migration method provided in this embodiment includes the following steps:

[0182] Step 601: Receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine.

[0183] In this context, the source virtual machine refers to the virtual machine that needs to be migrated. For example, if we migrate from virtual machine A to virtual machine B, then virtual machine A is called the source virtual machine, and virtual machine B is called the destination virtual machine.

[0184] Specifically, the source virtual machine sends preset metadata corresponding to each rendering data to be migrated, and the virtual GPU migration device in the destination virtual machine instructs the destination virtual machine to receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine.

[0185] Step 602: Reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0186] Specifically, after receiving the preset metadata corresponding to each rendering data to be migrated, the rendering data is reconstructed in the destination virtual machine based on the preset metadata, so that the rendering data in the destination virtual machine is consistent with the source virtual machine.

[0187] The virtual GPU migration method provided in this application receives preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine; and reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated. The received preset metadata corresponding to each rendering data corresponds to each rendering data, eliminating the need to migrate excessive data and improving migration efficiency; by reconstructing the rendering data based on the received preset metadata corresponding to each rendering data to be migrated, the virtual GPU migration can be completed, achieving real-time migration without the user's awareness.

[0188] As an optional implementation, based on the above embodiments, the method further includes:

[0189] Receive at least one rendering resource located in the physical graphics processing unit (GPU) sent by the source virtual machine;

[0190] Reconstructing rendering data based on at least one rendering resource.

[0191] Specifically, some types of rendering resources may have a portion of the rendering resources located in the physical GPU. In such cases, it is also necessary to receive at least one rendering resource located in the physical GPU sent by the source virtual machine and reconstruct the rendering data based on at least one rendering resource.

[0192] The virtual GPU migration method provided in this application further includes: receiving at least one rendering resource located in the physical graphics processing unit (GPU) sent by the source virtual machine; and reconstructing rendering data based on the at least one rendering resource. When a rendering resource is located in the physical GPU, it is also necessary to receive at least one rendering resource located in the physical GPU sent by the source virtual machine and reconstruct rendering data based on the at least one rendering resource. This ensures data integrity during the migration process and avoids data loss.

[0193] As an optional implementation, based on the above embodiments, the method further includes:

[0194] In response to the start of receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the migration thread is set to the state where rendering data writing has started.

[0195] Specifically, before receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the migration thread will first receive the virtual GPU status information sent by the source virtual machine. After receiving this information, the migration thread will update the current status to the state where rendering data writing has started.

[0196] The virtual GPU migration method provided in this application further includes: in response to starting to receive preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, setting the migration thread to a rendering data start writing state. Updating the current state of the migration thread to the rendering data start writing state allows the migration thread to run in an orderly manner, improving the effectiveness of resource reconstruction. Furthermore, by updating the state, the migration thread can begin preparing to receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine.

[0197] As an optional implementation, based on the above embodiments, after receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the method further includes:

[0198] Set the migration thread to the state where rendering data writing is complete.

[0199] Specifically, after the migration thread receives all the preset metadata, it will update the rendering data writing start status to the rendering data writing finish status.

[0200] The virtual GPU migration method provided in this application, after receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, further includes: setting the migration thread to the rendering data write completion state. By using the migration thread to promptly update the rendering data write start state to the rendering data write completion state, correct synchronization with the rendering thread can be achieved, ensuring the smooth migration of the virtual GPU.

[0201] As an optional implementation, based on the above embodiments, before reconstructing the rendering data based on the preset metadata corresponding to each rendering data to be migrated, the method further includes:

[0202] The rendering thread is used to determine whether the current state is the end of rendering data writing.

[0203] The rendering data is reconstructed based on the preset metadata corresponding to each rendering data to be migrated, including:

[0204] In response to the rendering thread determining that the current state is the end of rendering data writing, the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0205] Specifically, during its daily work, the rendering thread periodically determines whether the current state is the end of rendering data writing. When the rendering thread determines that the current state is the end of rendering data writing, it will reconstruct the rendering data based on the preset metadata corresponding to each of the received rendering data to be migrated.

[0206] The virtual GPU migration method provided in this application, before reconstructing the rendering data based on the preset metadata corresponding to each rendering data to be migrated, further includes: using a rendering thread to determine whether the current state is a rendering data writing completion state; and reconstructing the rendering data based on the preset metadata corresponding to each rendering data to be migrated, including: in response to the rendering thread determining that the current state is a rendering data writing completion state, using the rendering thread to reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated. Using the rendering thread to determine whether the current state is a rendering data writing completion state, and only starting resource reconstruction when it is determined to be a rendering data writing completion state, can ensure that the rendering thread can promptly learn of changes in the current state, improving the efficiency of the target virtual machine during resource reconstruction. On the other hand, it ensures the orderly operation of the rendering thread, avoiding data loss caused by starting reconstruction before all structures have been received.

[0207] As an optional implementation, based on the above embodiments, before the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, the method further includes:

[0208] The rendering thread is used to determine whether the current state is the end of rendering data writing.

[0209] If not, the rendering thread will continue processing the rendering instructions.

[0210] Specifically, the rendering thread periodically checks whether the current state is the end of rendering data writing. If the result is that the current state is the end of rendering data writing, then the rendering data reconstruction begins. If the result is not, it means that no virtual GPU is currently migrating or the migration thread has not yet received all the preset metadata, and the rendering thread will continue to process the rendering instructions.

[0211] The virtual GPU migration method provided in this application, before the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, further includes: using the rendering thread to determine whether the current state is a rendering data writing completion state; if not, using the rendering thread to continue processing rendering instructions. By using the rendering thread to determine whether the current state is a rendering data writing completion state, the latest state can be obtained in a timely manner so that the next action can be taken based on the latest state. If the current state is not a rendering data writing completion state, then the rendering thread continues to process rendering instructions, which can both obtain the latest state in a timely manner and not affect the daily work of the rendering thread.

[0212] As an optional implementation, based on the above embodiments, after the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, the method further includes:

[0213] Set the rendering thread to an idle state and continue processing rendering commands using the rendering thread.

[0214] Specifically, after the rendering thread completes the reconstruction of the rendering data, it writes the rendering data to the end state to update it to the idle state, and then continues to process rendering instructions.

[0215] The virtual GPU migration method provided in this application includes, after the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, setting the rendering thread to an idle state and continuing to process rendering instructions. After reconstructing the rendering data, the rendering thread promptly updates its current state to an idle state so that it can continue to process rendering instructions, ensuring the orderly operation of the rendering thread.

[0216] Figure 7 This embodiment of the application provides a flowchart of the migration thread and rendering thread in the source virtual machine during migration. It is understood that if the rendering thread cannot be properly stopped at the start of migration, it will continue processing rendering instructions, leading to data corruption. Therefore, this embodiment provides a method for virtual GPU migration by determining the current state, ensuring proper synchronization between the rendering thread and the migration thread during the migration process. Figure 7 As shown, the left side illustrates the workflow of the migration thread located in the source virtual machine during migration, as provided in this embodiment, while the right side illustrates the workflow of the rendering thread located in the source virtual machine during migration, as provided in this embodiment. The workflow of the migration thread located in the source virtual machine during migration includes the following steps:

[0217] Step 701a: In response to receiving the instruction to call the migration interface, the current state is set to the state where rendering data reading begins.

[0218] Step 702b: Determine whether the current state is the state where rendering data has been read.

[0219] Step 703c: If so, send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine.

[0220] If not, proceed to step 702b after the first preset time interval.

[0221] Step 705e: Update the rendering data reading completed status to idle status.

[0222] The workflow of the rendering thread located in the source virtual machine during migration includes the following steps:

[0223] Step 701A: Determine whether the current state is the state where rendering data has started reading.

[0224] Step 702B: If yes, obtain the preset metadata corresponding to each rendering data to be migrated in the system memory.

[0225] Step 703C: If not, continue processing rendering instructions.

[0226] Step 704D: Update the rendering data reading start status to the rendering data reading complete status.

[0227] Step 705E: Determine whether the current state is an idle state.

[0228] Step 706F: If yes, then shut down the rendering thread.

[0229] Step 707G: If not, continue with step 705E after a second preset time interval.

[0230] It should be noted that in the virtual GPU, the rendering instructions are processed by a separate rendering thread, while the migration of the virtual GPU is handled by a separate migration thread. Since the rendering thread and the migration thread are two independent threads, their workflows do not interfere with each other during the migration process. Therefore, the execution order of steps 701a-705e and steps 701A-707G is not important.

[0231] In this embodiment, the implementation methods and technical effects of steps 701a-705e and steps 701A-707G are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0232] Figure 8 This embodiment of the application provides a flowchart of the migration thread and rendering thread of the destination virtual machine during migration. It is understood that if the rendering thread starts processing rendering instructions before the destination virtual machine has completed the reconstruction of rendering data, it will also disrupt the entire resource reconstruction process and cause virtual machine errors. Therefore, this embodiment provides a method for virtual GPU migration by determining the current state, ensuring that the rendering thread and migration thread can be correctly synchronized during the migration process. Figure 8 As shown, the left side illustrates the workflow of the migration thread located in the destination virtual machine during migration, as provided in this embodiment, while the right side illustrates the workflow of the rendering thread located in the destination virtual machine during migration, as provided in this embodiment. The workflow of the migration thread located in the destination virtual machine during migration includes the following steps:

[0233] Step 801a: In response to receiving the virtual GPU status information from the source virtual machine, update the current status to the state where rendering data has started being written.

[0234] Step 802b: Receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine.

[0235] Step 803c: Update the rendering data writing start status to the rendering data writing end status.

[0236] The workflow of the rendering thread in the destination virtual machine during migration includes the following steps:

[0237] Step 801A: Determine whether the current state is the end of rendering data writing.

[0238] Step 802B: If yes, reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0239] Step 803C: If not, continue processing rendering instructions.

[0240] Step 804D: Write the rendering data to the end state to update to the idle state, and continue processing rendering instructions.

[0241] It should be noted that in the virtual GPU, the rendering instructions are processed by a separate rendering thread, while the migration of the virtual GPU is handled by a separate migration thread. Since the rendering thread and the migration thread are two independent threads, their workflows do not interfere with each other during the migration process. Therefore, the execution order of steps 801a-803c and steps 801A-804D is not important.

[0242] In this embodiment, the implementation methods and technical effects of steps 801a-803c and steps 801A-804D are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0243] Figure 9 A signaling interaction flowchart for a virtual GPU migration method provided in an embodiment of this application is shown below. Figure 9 As shown, the virtual GPU migration method provided in this embodiment includes the workflow of the source virtual machine during migration, the workflow of the destination virtual machine during migration, and the data transfer process between the source virtual machine and the destination virtual machine. Therefore, the virtual GPU migration method provided in this embodiment includes the following steps:

[0244] Step 901: The source virtual machine uses the standard virtual machine migration process to begin sending the source virtual machine's memory to the destination virtual machine.

[0245] Step 902: The destination virtual machine uses the standard virtual machine migration process to begin receiving memory from the source virtual machine.

[0246] Step 903: When the shutdown conditions are met, the source virtual machine stops running.

[0247] Step 904: The source virtual machine sends the register contents of the virtual central processing unit and information of each virtual device to the destination virtual machine.

[0248] Step 905: The destination virtual machine receives the register contents of the virtual central processing unit and information of each virtual device from the source virtual machine.

[0249] Step 906: In response to receiving an instruction to call the migration interface, create at least one structure in the source virtual machine.

[0250] Step 907: Store the preset metadata corresponding to each rendering data located in the source virtual machine system memory into the corresponding structure.

[0251] Step 908: Call the corresponding application programming interface (API) to store each rendering resource located in the physical GPU of the source virtual machine into the corresponding structure.

[0252] Step 909: Send each structure to the destination virtual machine and shut down the source virtual machine.

[0253] Step 910: The destination virtual machine receives at least one structure sent by the source virtual machine.

[0254] Step 911: After receiving the data, the target virtual machine reconstructs the rendering data based on the preset metadata corresponding to the rendering data in each structure.

[0255] It should be noted that steps 901-905 are the standard process for virtual machine migration, and will not be elaborated further here.

[0256] In this embodiment, the implementation method and technical effect of steps 906-911 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0257] Figure 10 This is a schematic diagram of the structure of a virtual GPU migration device provided in an embodiment of this application, as shown below. Figure 10 As shown, the virtual GPU migration device provided in this embodiment is located in the source virtual machine. Therefore, the virtual GPU migration device 100 provided in this embodiment includes: an acquisition module 1001 and a sending module 1002.

[0258] The acquisition module 1001 is used to acquire the preset metadata corresponding to each rendering data to be migrated in the system memory in response to receiving the instruction to call the migration interface; the sending module 1002 is used to send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, so that the destination virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0259] The virtual GPU migration device provided in this embodiment can perform... Figure 3 The methods provided in the embodiments are similar in their specific implementation principles and technical effects, and will not be described in detail here.

[0260] Optionally, the acquisition module 1001, when acquiring the preset metadata corresponding to each rendering data to be migrated in the system memory, is specifically used to: create multiple structures, wherein each structure corresponds to each rendering data to be migrated; and acquire the corresponding preset metadata from each rendering data to be migrated based on the structure.

[0261] Optionally, each structure is pre-configured with rendering data metadata information to be extracted. When the acquisition module 1001 obtains the corresponding preset metadata from each rendering data to be migrated based on the structure, it is specifically used to: extract preset metadata from each rendering data to be migrated located in the system memory according to the rendering data metadata information, so as to obtain the corresponding preset metadata from each rendering data to be migrated.

[0262] Optionally, the acquisition module 1001 is further configured to acquire at least one rendering resource located in the physical graphics processor (GPU) and save the at least one rendering resource to system memory; the sending module 1002 is further configured to send the at least one rendering resource to the destination virtual machine.

[0263] Optionally, the virtual GPU migration apparatus provided in this embodiment further includes a determination module and a calling module.

[0264] Accordingly, the determination module is used to determine the data dimension of at least one rendering resource and determine the corresponding API based on the data dimension; the invocation module is used to invoke the corresponding API to store at least one rendering resource in system memory.

[0265] Optionally, the virtual GPU migration device provided in this embodiment further includes a setting module.

[0266] Accordingly, the setting module is used to set the migration thread to the rendering data start reading state in response to receiving the instruction to call the migration interface; the acquisition module 1001, when acquiring the preset metadata corresponding to each rendering data to be migrated in the system memory, is specifically used to: in response to the rendering thread determining the current state to be the rendering data start reading state, acquire the preset metadata corresponding to each rendering data to be migrated in the system memory using the rendering thread.

[0267] Optionally, the virtual GPU migration apparatus provided in this embodiment further includes a determination module and a processing module.

[0268] Accordingly, a determination module is used to determine whether the current state is the state where rendering data reading has begun, using the rendering thread; and a processing module is used to continue processing rendering instructions using the rendering thread if not.

[0269] Optionally, the settings module can also be used to set the rendering thread to a state where rendering data has been read.

[0270] Optionally, when sending the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, the sending module 1002 is specifically used to: in response to the migration thread determining that the current state is the rendering data reading completion state, send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine using the migration thread.

[0271] Optionally, the determining module is further configured to use a migration thread to determine whether the current state is a state where rendering data has been read; if not, the step of using a migration thread to determine whether the current state is a state where rendering data has been read continues to be executed after a first preset time interval.

[0272] Optionally, the virtual GPU migration device provided in this embodiment further includes a shutdown module.

[0273] Accordingly, the settings module is also used to set the migration thread to an idle state; the shutdown module is used to shut down the rendering thread in response to the rendering thread determining that the current state is idle.

[0274] Optionally, the determining module is also used to determine whether the current state is an idle state using the rendering thread; if not, the step of determining whether the current state is an idle state using the rendering thread continues to be executed after a second preset time interval.

[0275] Figure 11 A schematic diagram of the structure of a virtual GPU migration device provided in another embodiment of this application is shown below. Figure 11 As shown, the virtual GPU migration device provided in this embodiment is located in the target virtual machine. Therefore, the virtual GPU migration device 110 provided in this embodiment includes: a receiving module 1101 and a reconstruction module 1102.

[0276] The receiving module 1101 is used to receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine; the reconstruction module 1102 is used to reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

[0277] The virtual GPU migration device provided in this embodiment can perform... Figure 6 The methods provided in the embodiments are similar in their specific implementation principles and technical effects, and will not be described in detail here.

[0278] Optionally, the receiving module 1101 is further configured to receive at least one rendering resource located in the physical graphics processor GPU sent by the source virtual machine; the reconstruction module 1102 is further configured to reconstruct rendering data based on at least one rendering resource.

[0279] Optionally, the virtual GPU migration device provided in this embodiment further includes a setting module.

[0280] Accordingly, a setting module is used to acquire preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, and set the migration thread to the rendering data writing state.

[0281] Optionally, the settings module is also used to set the migration thread to the end state of rendering data writing.

[0282] Optionally, the virtual GPU migration apparatus provided in this embodiment further includes a determination module.

[0283] Accordingly, the determination module is used to determine whether the current state is the end state of rendering data writing using the rendering thread; the reconstruction module 1102, when reconstructing the rendering data based on the preset metadata corresponding to each rendering data to be migrated, is specifically used to: in response to the rendering thread determining that the current state is the end state of rendering data writing, reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated using the rendering thread.

[0284] Optionally, the virtual GPU migration device provided in this embodiment further includes a processing module.

[0285] Accordingly, the determination module is also used to determine whether the current state is the end state of rendering data writing using the rendering thread; the processing module is used to continue processing the rendering instructions using the rendering thread if not.

[0286] Optionally, the settings module is also used to set the rendering thread to an idle state; the processing module is also used to continue processing rendering instructions using the rendering thread.

[0287] Figure 12 A schematic diagram of the structure of a virtual GPU migration device provided in an embodiment of this application is shown below. Figure 12 As shown, the virtual GPU migration device 120 provided in this embodiment includes: a processor 1201, a memory 1202 and a transceiver 1203 that are communicatively connected to the processor.

[0288] The memory 1202 stores computer-executed instructions; the processor 1201 executes the computer-executed instructions stored in the memory 1202 and controls the transceiver 1203 to send and receive data, thereby implementing the virtual GPU migration method provided in the embodiments applied to the source virtual machine and the destination virtual machine. Related explanations can be understood by referring to the relevant descriptions and effects corresponding to the steps in the accompanying drawings, and will not be elaborated upon here.

[0289] The program may include program code, which includes computer-executable instructions. Memory 1202 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0290] In this embodiment, the processor 1201, memory 1202, and transceiver 1203 are connected via a bus. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0291] This application also provides a computer-readable storage medium storing computer-executable instructions. When the controller executes the computer-executable instructions, it implements the various steps in the methods described above.

[0292] This application also provides a computer program product, including a computer program that, when executed by a controller, implements the various steps in the methods described above.

[0293] The various embodiments described above in this application can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0294] The computer-executable instructions used to implement the methods of this application may be written in any combination of one or more programming languages. These computer-executable instructions may be provided to the processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the computer-executable instructions cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer-executable instructions may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a standalone software package, or entirely on a remote machine or electronic device.

[0295] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be a machine-readable signal medium or a machine-readable storage medium. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Alternatively, computer-readable storage media may include: resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), and so on.

[0296] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as data electronic devices), or computing systems that include middleware components (e.g., application electronic devices), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0297] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to this application. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application. In other words, the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps disclosed in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0298] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0299] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0300] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0301] When an integrated unit / module is implemented in hardware, that hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc.

[0302] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing computer-executable instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0303] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0304] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only.

[0305] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Therefore, the specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this application should be included within the scope of protection of this application.

Claims

1. A method for migrating a virtual GPU, characterized in that, The method is applied to the source virtual machine, and the method includes: In response to receiving an instruction to call the migration interface, the system retrieves the preset metadata corresponding to each rendering data to be migrated in the system memory; The preset metadata corresponding to each of the rendering data to be migrated is sent to the target virtual machine, so that the target virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each of the rendering data to be migrated.

2. The method according to claim 1, characterized in that, The step of obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory includes: Create multiple structures, each of which corresponds to a rendering data to be migrated; Based on the structure, the corresponding preset metadata is obtained from each of the rendering data to be migrated.

3. The method according to claim 2, characterized in that, Each of the aforementioned structures is pre-configured with metadata information of the rendering data to be extracted; The step of obtaining corresponding preset metadata from each of the rendering data to be migrated based on the structure includes: The preset metadata is extracted from each of the rendering data to be migrated located in the system memory according to the rendering data metadata information, so as to obtain the corresponding preset metadata from each of the rendering data to be migrated.

4. The method according to claim 1, characterized in that, The rendering data includes rendering resources and a rendering context, and the method further includes: Acquire at least one rendering resource located in the physical graphics processor (GPU) and save the at least one rendering resource to the system memory; Send the at least one rendering resource to the destination virtual machine.

5. The method according to claim 4, characterized in that, Saving the at least one rendering resource to the system memory includes: Determine the data dimensions of the at least one rendering resource, and determine the corresponding API based on the data dimensions; Call the corresponding API to store at least one rendering resource into the system memory.

6. The method according to claim 1, characterized in that, Before obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory, the method further includes: In response to receiving an instruction to call the migration interface, the migration thread is set to the state where rendering data reading has begun; The step of obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory includes: In response to the rendering thread determining that the current state is the start of reading rendering data, the rendering thread obtains the preset metadata corresponding to each rendering data to be migrated in the system memory.

7. The method according to claim 6, characterized in that, Before obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory using the rendering thread, the method further includes: The rendering thread is used to determine whether the current state is the state where rendering data reading has begun; If not, the rendering thread will continue processing the rendering instructions.

8. The method according to claim 6, characterized in that, After obtaining the preset metadata corresponding to each rendering data to be migrated in the system memory using the rendering thread, the method further includes: The rendering thread is set to the state where rendering data has been read.

9. The method according to claim 8, characterized in that, Sending the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine includes: In response to determining that the current state is "rendering data reading complete" using the migration thread, the migration thread sends the preset metadata corresponding to each render data to be migrated to the destination virtual machine.

10. The method according to claim 9, characterized in that, After setting the migration thread to the state where rendering data reading has begun, the method further includes: The migration thread is used to determine whether the current state is a state where rendering data reading is complete; If not, the process of determining whether the current state is "rendering data reading completed" using the migration thread will continue after a first preset time interval.

11. The method according to claim 9, characterized in that, After the migration thread sends the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, the method further includes: Set the migration thread to an idle state; In response to the rendering thread determining that the current state is idle, the rendering thread is shut down.

12. The method according to claim 11, characterized in that, After setting the rendering thread to the state where rendering data reading is complete, the method further includes: The rendering thread is used to determine whether the current state is idle. If not, the step of determining whether the current state is idle using the rendering thread will continue after a second preset time interval.

13. A method for migrating a virtual GPU, characterized in that, The method is applied to a target virtual machine, and the method includes: Receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine; The rendering data is reconstructed based on the preset metadata corresponding to each of the rendering data to be migrated.

14. The method according to claim 13, characterized in that, The method further includes: Receive at least one rendering resource located in the physical graphics processing unit (GPU) sent by the source virtual machine; Reconstructing rendering data based on at least one of the rendering resources.

15. The method according to claim 13, characterized in that, The method further includes: In response to the start of receiving preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the migration thread is set to the rendering data writing state.

16. The method according to claim 15, characterized in that, After receiving the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine, the method further includes: Set the migration thread to the state where rendering data writing is complete.

17. The method according to any one of claims 15-16, characterized in that, Before reconstructing the rendering data based on the preset metadata corresponding to each of the rendering data to be migrated, the method further includes: The rendering thread is used to determine whether the current state is the end state of the rendering data writing; The reconstruction of rendering data is performed based on the preset metadata corresponding to each rendering data to be migrated, including: In response to the rendering thread determining that the current state is the end state of the rendering data writing, the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

18. The method according to claim 17, characterized in that, Before the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, the method further includes: The rendering thread is used to determine whether the current state is the end state of the rendering data writing; If not, the rendering thread continues to process the rendering instructions.

19. The method according to claim 17, characterized in that, After the rendering thread reconstructs the rendering data based on the preset metadata corresponding to each rendering data to be migrated, the method further includes: The rendering thread is set to an idle state, and the rendering thread continues to process rendering instructions.

20. A virtual GPU migration device, characterized in that, The device is located in the source virtual machine, and the device includes: The acquisition module is used to obtain the preset metadata corresponding to each rendering data to be migrated in the system memory in response to the instruction to call the migration interface. The sending module is used to send the preset metadata corresponding to each rendering data to be migrated to the destination virtual machine, so that the destination virtual machine can reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

21. A virtual GPU migration device, characterized in that, The device is located in the target virtual machine, and the device includes: The receiving module is used to receive the preset metadata corresponding to each rendering data to be migrated sent by the source virtual machine; The reconstruction module is used to reconstruct the rendering data based on the preset metadata corresponding to each rendering data to be migrated.

22. A virtual GPU migration device, characterized in that, The device includes: a processor, and a memory and a transceiver communicatively connected to the processor; The memory stores computer-executed instructions; the transceiver is used for sending and receiving data. The processor executes computer execution instructions stored in the memory to implement the method as claimed in any one of claims 1 to 12 or the method as claimed in any one of claims 13 to 19.

23. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1 to 19.

Images