Driver upgrading method and electronic equipment

Abstract

The invention provides a driver upgrading method which comprises the following steps: in response to a received driver upgrading instruction for a target processing unit, determining a target process which is a process for executing a target task based on the target processing unit; suspending the instruction transmission process of each target process to the target processing unit so as to suspend the executed target task; and in response to pause of each instruction transmission process, upgrading the driver of the target processing unit based on the driver upgrading request. The invention further provides the electronic equipment used for executing the method.

Description

Technical Field

[0001] The present disclosure relates to the field of computer random numbers, and more specifically, to a driver upgrade method and electronic device. Background Art

[0002] Specialized processing units (TPUs), such as various accelerators and coprocessors (hereinafter collectively referred to as TPUs), have been widely adopted in key areas such as high-performance computing, artificial intelligence, and big data analytics due to their efficient parallel processing capabilities and specialized task handling advantages. As the core software layer between the operating system and the hardware, TPU drivers are essential for fully leveraging hardware performance, fixing known defects, and supporting emerging software and hardware ecosystems.

[0003] Traditional target processing unit driver upgrades often face significant technical challenges. Typically, upgrading the target processing unit's driver requires terminating all running processes, applications, or services on the target processing unit node that depend on it. Coordinating the orderly termination and subsequent restart of all processes often requires extensive manual intervention and complex cross-departmental or cross-system coordination, a cumbersome and error-prone process. During the driver upgrade, the termination of processes directly leads to interruptions in computing tasks, severely impacting business continuity and user experience. Summary of the Invention

[0004] In view of this, the present disclosure provides a drive upgrade method and an electronic device.

[0005] One aspect of the present disclosure provides a driver upgrade method, comprising: in response to receiving a driver upgrade instruction for a target processing unit, confirming a target process, where the target process is a process that executes a target task based on the target processing unit; pausing the instruction transmission process of each target process to the target processing unit to suspend the executed target task; and in response to the suspension of each instruction transmission process, upgrading the driver of the target processing unit based on the driver upgrade request.

[0006] According to an embodiment of the present disclosure, the driver upgrade method further includes: in response to completion of the driver upgrade, resuming the instruction transmission process of each target process to the target processing unit, so that each target process continues to execute the target task based on the target processing unit.

[0007] According to an embodiment of the present disclosure, the process of a target process executing a target task based on a target processing unit includes: sending a target instruction to a first target function module based on the target process, so that the first target function module calls the corresponding second target function module in the target processing unit to execute the target task.

[0008] According to an embodiment of the present disclosure, pausing the instruction transmission process of each target process to the target processing unit includes: controlling the first target function module to enter a dormant state to prevent the first target function module from calling the second target function module in the target processing unit.

[0009] According to an embodiment of the present disclosure, after controlling the first target functional module to enter a sleep state, it also includes: controlling the first target functional module to perform the following functions until a stop condition is met: cyclically detecting whether the driver of the target processing unit is upgraded; the stop condition includes: the driver upgrade of the target processing unit is completed.

[0010] According to an embodiment of the present disclosure, in response to the completion of the driver upgrade, the instruction transmission process of each target process to the target processing unit is restored so that each target process continues to execute the target task based on the target processing unit, including: in response to the completion of the driver upgrade, controlling the first target function module to enter the working state, so that the first target function module calls the corresponding second target function module in the target processing unit to continue to execute the target task.

[0011] According to an embodiment of the present disclosure, before upgrading the driver of the target processing unit, the driver upgrade method also includes: saving target data associated with each target process in the target processing unit; before restoring the instruction transmission process of each target process to the target processing unit, it also includes: restoring the data associated with each target process in the target processing unit based on the target data.

[0012] According to an embodiment of the present disclosure, the driver upgrade method also includes: generating and saving registration information of the target process in response to the creation of the target process; deleting the registration information corresponding to the target process in response to the deregistration of the target process; confirming the target process, including: confirming each target process based on the saved registration information.

[0013] According to an embodiment of the present disclosure, upgrading the driver of the target processing unit includes: releasing usage information of the first target function module corresponding to each target process in the target processing unit; and upgrading the driver of the target processing unit according to a driver upgrade request.

[0014] Another aspect of the present disclosure provides a driver upgrade device, including: a first confirmation module, used to confirm the target process in response to receiving a driver upgrade instruction for the target processing unit, the target process being a process that executes a target task based on the target processing unit; a first pause module, used to pause the instruction transmission process of each target process to the target processing unit to pause the executed target task; and a first upgrade module, used to upgrade the driver of the target processing unit based on the driver upgrade request in response to the pause of each instruction transmission process.

[0015] Another aspect of the present disclosure provides an electronic device comprising: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the driver upgrade method of any one of the aforementioned embodiments.

[0016] Another aspect of the present disclosure provides a computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the driver upgrade method according to any one of the aforementioned embodiments.

[0017] Another aspect of the present disclosure provides a computer program product, including a computer program / instruction, characterized in that when the computer program / instruction is executed by a processor, the operation of the driver upgrade method of any of the aforementioned embodiments is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0019] Figure 1 The following schematically shows a flow chart of a driver upgrade method according to an embodiment of the present disclosure;

[0020] Figure 2 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0021] Figure 3 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0022] Figure 4 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0023] Figure 5 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0024] Figure 6 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0025] Figure 7 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0026] Figure 8 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown;

[0027] Figure 9 The following schematically shows a block diagram of a driver upgrade process according to an embodiment of the present disclosure;

[0028] Figure 10 Schematically shows a driver upgrade timing diagram according to an embodiment of the present disclosure;

[0029] Figure 11 A block diagram schematically shows a drive upgrade device according to an embodiment of the present disclosure; and

[0030] Figure 12 A block diagram of an electronic device suitable for implementing the above-described method according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0031] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present disclosure. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0032] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise," "include," etc. used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0033] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0034] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0035] In the embodiments of this disclosure, the collection, updating, analysis, processing, use, transmission, provision, disclosure, and storage of all data involved (including, but not limited to, user personal information) comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. In particular, necessary measures have been taken to prevent unauthorized access to user personal information data and to safeguard the security of user personal information, network security, and national security.

[0036] An embodiment of the present disclosure provides a driver upgrade method, comprising: in response to receiving a driver upgrade instruction for a target processing unit, confirming a target process, where the target process is a process that executes a target task based on the target processing unit; pausing the instruction transmission process of each target process to the target processing unit to suspend the executed target task; and in response to the suspension of each instruction transmission process, upgrading the driver of the target processing unit based on the driver upgrade request.

[0037] Figure 1 The flowchart of the driver upgrade method according to the embodiment of the present disclosure is schematically shown.

[0038] like Figure 1 As shown, the driver upgrade method may include at least operations S110 to S130.

[0039] In operation S110 , in response to receiving a driver upgrade instruction for a target processing unit, a target process is confirmed, where the target process is a process that executes a target task based on the target processing unit.

[0040] The target processing unit can be a hardware computing device or a specific software system capable of executing parallel computing tasks and serving as the underlying hardware or software resource for executing the target tasks. The target processing unit interacts with the operating system and application software through its driver. For example, it can be a graphics processing unit (GPU), a specialized processor used to accelerate graphics rendering or general-purpose parallel computing; it can be a dedicated integrated circuit processing unit custom-designed for a specific computing task; or it can be a programmable logic array device configured to execute a specific target task.

[0041] The driver upgrade instruction may be a control signal or an instruction set for instructing to update or replace the existing driver of the target processing unit.

[0042] A target process is an instantiated program running in an operating system that relies on the computing power provided by the target processing unit for at least some of its computational tasks. For example, this could be an application process training a machine learning model that calls the target processing unit to perform large-scale numerical calculations, or a server process providing real-time data stream analysis services that uses the target processing unit to accelerate data processing.

[0043] Specifically, after receiving a driver upgrade instruction for a specific target processing unit, one or more active processes currently using the target processing unit to perform their computing tasks will be identified.

[0044] For example, suppose a computing server is configured with a graphics processing unit (GPU) as the target processing unit. When it receives an instruction to upgrade the GPU driver from an older version to a newer version, it first checks which processes are currently using the GPU. If it finds that both process A (a machine learning training task running using a parallel computing framework, whose compute-intensive operations are performed on the GPU) and process B (an application providing real-time image processing services, whose image processing algorithms are accelerated on the GPU) are using the GPU for computing, then process A and process B are identified as target processes.

[0045] In operation S120 , the instruction transmission process of each target process to the target processing unit is suspended to suspend the execution of the target task.

[0046] The instruction transmission process can be the interactive path and behavior sequence in which the target process submits computing instructions, data transmission instructions, or status query instructions to the driver or hardware itself of the target processing unit by calling specific application programming interface (API) functions or sending operation control codes.

[0047] Specifically, for each identified target process, measures are taken to temporarily prevent it from sending new operational instructions to its associated target processing unit. This pause does not terminate the target process, but rather causes it to enter a controlled wait state while attempting to communicate with the target processing unit, thereby temporarily suspending the execution of target tasks that depend on these new instructions. For example, when a target process attempts to call a library function that interacts with the GPU, the execution of that function is delayed, causing the target process to wait for the function to return, during which time no new instructions are actually passed to the GPU.

[0048] For example, after confirming that process A and process B are the target processes, when process A (the machine learning training task) attempts to coordinate its computations on the GPU by calling a function in its GPU-oriented parallel computing programming interface (for example, a function used to synchronize computational flows on the GPU), the call to this API function is intercepted and placed in a waiting state. Similarly, when process B (the image processing service) attempts to call a function in its GPU-oriented parallel computing programming interface (for example, a function used to allocate space in GPU device memory) to prepare for new input image data, the call is also placed in a waiting state. As a result, the transmission of instructions from process A and process B to the GPU is suspended, and the target tasks (training and image processing) they are executing also suspend further computational processing on the GPU.

[0049] In operation S130 , in response to the suspension of each instruction transmission process, a driver of the target processing unit is upgraded based on the driver upgrade request.

[0050] Specifically, after confirming that all previously determined target processes have suspended their instruction transmission to the target processing unit, that is, ensuring that the target processing unit is not currently processing new instruction streams from these target processes, it will be based on the information contained in the received driver upgrade instruction.

[0051] For example, after both process A and process B have suspended transmitting instructions to the GPU, the GPU driver upgrade process begins according to the driver upgrade instruction. This may include first uninstalling the old driver core module associated with the GPU using a system command, then running the installation package of the new driver version (for example, a driver installation script or executable file provided by the GPU hardware vendor and suitable for the current operating system). The installation package copies the new driver files to a specified location, compiles and installs the new GPU driver core module, and finally loads the new GPU driver core module using a system command, completing the driver upgrade.

[0052] According to the embodiment of the present disclosure, by pausing the instruction transmission process from the target process to the target processing unit before the driver upgrade, rather than terminating the target process, it is possible to create safe conditions for the driver upgrade without interrupting the operation of the target process itself, thereby avoiding the risk of business interruption and data loss caused by the termination of related services or tasks due to the upgrade of the driver, improving the smoothness of the driver upgrade process and user experience, and is particularly suitable for computing platforms with high requirements for business continuity.

[0053] Figure 2 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0054] like Figure 2As shown, based on the above embodiment, the driver upgrade method may further include operation S210.

[0055] In operation S210 , in response to completion of the driver upgrade, the instruction transmission process of each target process to the target processing unit is resumed, so that each target process continues to execute the target task based on the target processing unit.

[0056] Specifically, after the target processing unit's driver is successfully upgraded to the new version and initialized, the previously suspended state imposed on each target process's instruction transmission to the target processing unit is released. This resumption operation allows instruction calls previously placed in a waiting state (for example, calls to GPU programming interface functions) to resume execution and successfully transmit the instructions to the target processing unit with the upgraded driver. As a result, each target process can resume normal interaction with the target processing unit from the point of suspension and continue executing its target task, which relies on the target processing unit's computing power, without the need for restarting or manual intervention in the process itself.

[0057] Continuing with the example above, after the graphics processing unit (GPU) driver has been successfully upgraded from an old version to a new one, a completion signal is issued. In response to this completion signal, calls to GPU programming interface functions (such as one for synchronizing GPU computations) by process A (the machine learning training task) and calls to GPU programming interface functions (such as one for allocating memory in the GPU device) by process B (the image processing service), which were previously blocked and placed in a waiting state, are now allowed to continue. These function calls interact with the newly installed GPU driver. Consequently, process A is able to continue its training computations on the GPU, and process B is able to continue its image processing operations on the GPU. Both target processes resume instruction transmission to the GPU and continue executing their respective tasks, creating a smooth transition for both processes A and B.

[0058] Based on the above-mentioned embodiment, the process of the target process executing the target task based on the target processing unit may include sending a target instruction to the first target function module based on the target process, so that the first target function module calls the corresponding second target function module in the target processing unit to execute the target task.

[0059] Specifically, when a target process needs to utilize the computing resources or functions of the target processing unit during the execution of its target task, it does not directly interact with the target processing unit's interface or native function library. Instead, the target process sends its intended operation (embodied as a target instruction, such as a function call request and its parameters) to a pre-defined "first target function module" that serves as an interface. This first target function module typically acts as a call proxy or encapsulation layer.

[0060] Preferably, the interface of the first target function module is consistent or similar in name and parameters to the native target processing unit function interface that the target process expects to call, that is, the second target function module (for example, a function in a standard GPU programming library). After receiving the target instruction, the first target function module is responsible for further calling the "second target function module" corresponding to the instruction located in the target processing unit (or its driver stack). The second target function module is the functional entity that actually executes the operations of the target processing unit (such as video memory allocation, kernel startup, data copying, etc.), that is, the native function or service provided by the target processing unit driver. Through this two-stage calling mechanism, the first target function module acts as a bridge between the target process and the native function of the target processing unit, thereby enabling the target task to be executed on the target processing unit.

[0061] For example, suppose a target process is an application that trains a machine learning model and utilizes the GPU for massively parallel computing. When the application needs to allocate a block of video memory on the GPU for training data, it issues a "target instruction," for example, calling a function named "Allocate Device Memory" (this function name, from the application's perspective, matches the function name provided by the standard GPU programming library) and specifies the required memory size as a parameter. The "Allocate Device Memory" function actually called by the application is the "first target function module," a proxy function that does not directly perform allocation operations on the GPU hardware. After receiving this memory allocation instruction, the proxy function, acting as the first target function module, further calls a native API function provided by the GPU driver (e.g., a low-level function corresponding to the standard library function for GPU memory allocation). This native API function in the GPU driver is the "second target function module." The second target function module then actually performs the memory allocation operation on the GPU, thereby completing part of the target task requested by the target process: "Allocate Device Memory."

[0062] Figure 3 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0063] like Figure 3 As shown, based on the above embodiment, S120 may include operation S310.

[0064] In operation S310 , the first target functional module is controlled to enter a dormant state to prevent the first target functional module from calling a second target functional module in a target processing unit.

[0065] When it is necessary to suspend the transmission of instructions from the target process to the target processing unit, the first target functional module is controlled to enter a "sleep state." This "sleep state" means that when the first target functional module receives a new target instruction (e.g., a function call) from the target process, its internal execution logic temporarily suspends or delays the actual call to the corresponding second target functional module (e.g., a native function provided by the GPU driver) in the target processing unit. In other words, after entering the sleep state, the first target functional module's function as an instruction relay is temporarily suppressed, effectively preventing new instructions from flowing through it to the second target functional module, and thus preventing these instructions from being executed on the target processing unit. This sleep state does not mean that the first target functional module itself stops running, but rather that its behavior when processing specific target instructions changes, from immediately forwarding calls to conditionally suspending calls.

[0066] For example, based on the examples in the preceding embodiments, assume a pause instruction is issued (e.g., to prepare for a GPU driver upgrade). When the target process (a machine learning training application) attempts to call a function that interacts with the GPU through the first target function module (a proxy function, such as the proxy's "Allocate Device Memory" function), the first target function module, which has been controlled to enter a "sleep state," does not immediately call the corresponding second target function module (the native "Allocate Device Memory" API function) in the GPU driver upon receiving this call. Instead, the internal logic of the first target function module may enter a wait loop or perform a delay operation, causing it to "sleep," which appears to extend the execution time of the proxy function in the program execution flow. During this period, because the first target function module does not call the second target function module, no new video memory allocation requests are actually submitted to the GPU driver. The target process's execution thread is blocked at the proxy function call point, waiting for the proxy function to return, thereby preventing it from submitting new operation instructions to the GPU.

[0067] According to the disclosed embodiments, by controlling the first target functional module to enter a dormant state, this method effectively blocks subsequent GPU operations at key nodes in the instruction transmission path (i.e., within the first target functional module) without terminating the target process. This approach avoids the complexity and risks associated with directly manipulating the target process itself, providing a more sophisticated and reliable instruction pause mechanism. This ensures that all new instructions submitted by the target process to the GPU are reliably paused at the first target functional module level before sensitive operations such as driver upgrades are required, creating a stable environment free from interference from new GPU activity for subsequent operations (such as data backup or driver kernel module uninstallation).

[0068] Figure 4 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0069] like Figure 4 As shown, based on the above embodiment, after S310 , an operation loop may be included to execute operation S410 until a stop condition is met.

[0070] In operation S410, it is cyclically detected whether the driver of the target processing unit is upgraded. The stop condition includes: the driver of the target processing unit is upgraded.

[0071] Specifically, after the first target function module enters a dormant state according to operation S310, and when the target process has called the first target function module, the internal execution logic of the first target function module will initiate a loop process. During this loop process, the first target function module will periodically and repeatedly query a preset status indicator or signal, which reflects the current status of the driver upgrade process of the target processing unit. This loop detection will continue until the status indicator or signal clearly indicates that the driver upgrade of the target processing unit has been completed. Once the sign indicating that the driver upgrade is complete is detected, that is, the "stop condition" is met, the first target function module will terminate the loop detection process.

[0072] For example, in the aforementioned Figure 4 Based on the example content in the illustrated embodiment, when the first target functional module (e.g., the proxy's "Allocate Device Memory" function) enters a dormant state due to a GPU driver upgrade and is called by the target process (a machine learning training application), a loop (e.g., a while loop) is initiated within the proxy function. Within this loop, the proxy function checks a global flag or shared memory variable maintained by a dedicated driver upgrade process at preset intervals (e.g., every several milliseconds). This flag is set to "in progress" at the start of the GPU driver upgrade and is updated to "completed" by the driver upgrade process after the new GPU driver is successfully installed and loaded. The proxy function continuously reads the value of this flag. As long as the flag indicates that the GPU driver upgrade is still "in progress," the loop continues. When the proxy function detects that the flag has changed to "completed," indicating that the GPU driver upgrade is complete and the stop condition has been met, the proxy function exits the while loop.

[0073] According to the disclosed embodiments, by having the first target functional module perform loop detection in a dormant state, this method ensures that the pause state for GPU instruction transmission can be accurately maintained until the GPU driver upgrade is actually completed. This mechanism enables the first target functional module to autonomously and in real time detect the completion of the driver upgrade without relying on complex external synchronization signals or fixed waiting times, thereby improving the accuracy and responsiveness of the switching between pause and resume timings.

[0074] Figure 5 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0075] like Figure 5 As shown, based on the above embodiment, S210 may include operation S510.

[0076] In operation S510 , in response to completion of the driver upgrade, the first target function module is controlled to enter a working state, so that the first target function module calls a corresponding second target function module in the target processing unit to continue executing the target task.

[0077] Specifically, when the first target functional module confirms through its internal detection mechanism (such as operation S410) that the driver of the target processing unit has been successfully upgraded, the first target functional module will switch from its previous "sleep state" to a "working state." Entering the "working state" means that the first target functional module resumes its normal instruction relay function. That is, for a target instruction (e.g., a function call) from the target process that was previously suspended due to the sleep state, or for a new target instruction subsequently issued by the target process, the first target functional module will now, in accordance with its design, actively and actually call the second target functional module of the target processing unit corresponding to the target instruction (e.g., a native function provided by the GPU driver). In this way, the instruction stream is ultimately transferred from the target process via the first target functional module to the second target functional module and executed by the target processing unit, allowing the suspended target task to continue its computational processing on the target processing unit.

[0078] For example, in the aforementioned Figure 4Based on the example content in the illustrated embodiment, when the first target functional module (e.g., the proxy's "Allocate Device Memory" function) detects that the flag in its internal while loop has changed to "Completed," indicating that the GPU driver upgrade is complete and exits the loop, the proxy function transitions from a "sleep state" to a "working state." At this point, the proxy function executes its normal business logic, using the parameters previously received from the target process (the machine learning training application) (e.g., the requested video memory size) to call the native API function (i.e., the second target functional module) provided by the newly upgraded GPU driver, which is responsible for allocating video memory on the GPU. Once the native API function completes and returns a result (e.g., the allocated GPU memory address or an error code), the proxy function returns this result to the calling target process. After receiving the return value, the target process continues its subsequent computing task as if it had completed a normal function call.

[0079] According to the embodiment of the present disclosure, by precisely controlling the first target functional module to resume from a dormant state to a working state after the driver upgrade is completed, it is ensured that the target process can seamlessly continue execution at the GPU operation point where it was previously paused, without the need for restarting the process itself or complex context recovery logic. The recovery process of instruction transmission is transparent to the target process, and the target process only perceives that the execution time of a GPU-related function it calls is slightly extended. This achieves smooth recovery of the target task, minimizes the actual perception of service interruption caused by the driver upgrade, ensures business continuity and user experience, and minimizes the impact of the entire GPU driver upgrade process on upper-layer applications.

[0080] Figure 6 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0081] like Figure 6 As shown, based on the above embodiment, operation S610 may be included before operation S130.

[0082] In operation S610, target data associated with each target process in the target processing unit is saved. The target data associated with each target process may include, but is not limited to, a set of dynamic or static data stored in a dedicated memory of the target processing unit, created, loaded, modified, or relied upon by each target process during execution of its specific target task, and necessary for the target task to continue to execute correctly and continuously after the driver upgrade.

[0083] Specifically, before the driver upgrade process of the target processing unit begins, especially before operations that may cause the loss of the target processing unit's memory contents (such as unloading and reloading the GPU driver kernel module) are executed, the critical data currently residing in the target processing unit's memory and associated with the running target processes (i.e., "target data") need to be copied and saved to a more stable storage location that will not be affected during the driver upgrade, such as the host system's central processing unit (CPU) memory or local disk storage. "Target data" refers to data allocated, generated, or used on the target processing unit when the target process performs its target task, which is critical for the continued execution of the task, such as intermediate calculation results, model parameters, texture data, frame buffer contents, etc. This save operation can be performed by the first target functional module. Since this module records the target process's application and use of the target processing unit's memory, it can identify the specific target processing unit's memory area and its size that need to be backed up.

[0084] For example, suppose a target process is an application performing a 3D rendering task. This application has stored its scene geometry data, texture maps, and intermediate calculation results of the rendering pipeline (such as the depth buffer and color buffer) in the GPU's dedicated video memory. These scene geometry data, texture maps, and intermediate rendering results stored in the GPU video memory constitute the "target data" associated with the rendering application. After the GPU driver upgrade instruction is issued and before the old driver kernel module is actually uninstalled, a data save operation is triggered. The first target function module, based on its recorded information on the rendering application's allocation of GPU video memory (for example, the pointer and size obtained through the proxy's GPU memory allocation function call), coordinates the copying of the contents of these GPU video memory areas (i.e., the target data) from the GPU video memory to a pre-allocated buffer in the host CPU memory via a high-speed data transmission interface, thereby completing the target data save.

[0085] Before operation S210 , operation S620 may be further included.

[0086] In operation S620 , data associated with each target process in the target processing unit is restored based on the target data.

[0087] Specifically, after the target processing unit's driver is successfully upgraded and initialized, but before each target process fully resumes its instruction transmission to the target processing unit (i.e., operation S210), the "target data" previously saved to the host memory or disk in operation S610 must be copied back to the target processing unit's memory. This restoration operation ensures that when the target process resumes execution, the target processing unit's data environment required by it remains consistent or equivalent to that before the driver upgrade.

[0088] This operation S620 can be completed based on the first target functional module. Furthermore, the first target functional module copies the data from the host memory back to the target processing unit, and may also need to process the changes in the memory address of the target processing unit. For example, if the memory address corresponding to the original target processing unit is no longer valid after the new driver is loaded, the first target functional module needs to apply for a new memory area on the target processing unit for the recovered data, and restore the data to the new area, while updating its internal records to ensure that when the target process accesses through the original variables or pointers, it can correctly point to the new physical location of the recovered data on the target processing unit.

[0089] For example, after a new GPU driver is successfully installed and loaded, but before the rendering application resumes its rendering loop, a data restoration operation is performed. The "target data" previously saved to the host CPU's memory (i.e., scene geometry, textures, and intermediate rendering results) is copied from the host memory buffer back to the GPU's video memory via a high-speed data transfer interface, coordinated by the first target function module. If GPU memory is cleared due to a driver reload, the first target function module first re-allocates GPU memory space for this data under the new driver environment and then performs the copy operation. After completing the data restoration, the first target function module ensures that pointers or handles used within the rendering application to access this data remain valid or are transparently redirected to the new location of the restored data on the GPU. This allows the rendering application to seamlessly continue using this restored "target data" for subsequent rendering calculations, as if the contents of GPU memory had never been lost.

[0090] According to the disclosed embodiments, by saving the target data related to the target process in the GPU before the driver upgrade, and restoring this data back to the GPU after the driver upgrade is complete and before the target process resumes execution, this method can effectively protect the working status and data integrity of the target process on the GPU, especially in situations where the driver upgrade involves kernel module reloading, which may cause GPU memory data loss. This data backup and recovery mechanism enables the target process to quickly and seamlessly resume execution from the interruption point after the driver upgrade, avoiding task failures caused by data loss or the huge overhead of reloading and recalculating data from scratch. It significantly improves the smoothness of the GPU driver upgrade process and its transparency to upper-level applications, ensures data continuity for critical tasks, reduces service interruption time, and increases user tolerance for platform maintenance operations.

[0091] Figure 7 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0092] like Figure 7As shown, based on the above embodiment, the driver upgrade method may include operations S710 to S730.

[0093] In operation S710 , in response to creation of a target process, registration information of the target process is generated and saved.

[0094] The registration information may include identification information for uniquely identifying a target process that has been created and is using or preparing to use a target processing unit; optionally, the registration information also includes auxiliary information required to drive the upgrade process to communicate or synchronize the status with the first target functional module of the target process.

[0095] Specifically, when a new target process is created in the operating system and the first target functional module is loaded or linked during its initialization process, the initialization routine of the first target functional module automatically performs a registration action. This registration action includes collecting identity information about its host target process (e.g., process ID) and identification information of its own instance, and combining this information into a structured "registration information." Subsequently, this newly generated registration information is transmitted to a unified registration management component (e.g., a centralized registry or active process list maintained by the driver upgrade process) and stored and managed by the component. This saved registration information provides a basis for accurately identifying all active target processes that rely on the target processing unit in the subsequent driver upgrade process.

[0096] For example, suppose an application (as the target process) designed to perform massively parallel computing is launched on a user system. During its startup and initialization phase, the application loads a dynamic link library (DLL) as the first target functional module. When the DLL's entry point function or initialization function is executed, it obtains the current application's operating system process ID (e.g., PID 5678) and may generate a unique proxy instance ID (e.g., ABC). It may also determine the GPU device number (e.g., GPU index 0) that the application will use. The call proxy layer then encapsulates this information ({PID: 5678, ProxyID: ABC, GPU_Index: 0}) into a registration message and sends it to a resident driver upgrade management process via a predefined inter-process communication mechanism (e.g., a named pipe or shared memory segment). Upon receiving this registration message, the driver upgrade management process adds it to a global registration list that records all active GPU user processes for persistent storage.

[0097] In operation S720 , in response to the deregistration of the target process, registration information corresponding to the target process is deleted.

[0098] Specifically, when a target process that has been previously registered through operation S710 ends its life cycle normally (for example, the task is completed and exited) or is forcibly terminated by the user or the system, a deregistration action will be triggered. This deregistration action is usually initiated by the cleanup or destruction routine of the operating system. The routine will notify the unified registration management component, indicating that its host target process is about to terminate or no longer uses the resources of the target processing unit. After receiving this deregistration instruction, the registration management component will search and remove the registration record corresponding to the terminated or deregistered target process in its saved registration information list based on the identification information provided in the deregistration request (for example, the process ID or the agent instance ID). This deletion operation ensures the real-time and accuracy of the registration list, so that it only contains target processes that are still active and need to be included in the driver upgrade coordination scope.

[0099] For example, when the application (target process) with PID 5678 completes its parallel computing tasks and exits normally, the operating system begins reclaiming its occupied resources. During this process, the unload routine or destructor of the dynamic link library loaded as the first target functional module is called. This routine constructs a deregistration message containing identification information sufficient to identify the target process (for example, PID: 5678 or ProxyID: ABC) and sends this message to the driver upgrade management process. Upon receiving this deregistration message, the driver upgrade management process searches for the registration entry associated with PID 5678 (or ABC) in its global active GPU user process registration list and removes it from the list. Therefore, in subsequent GPU driver upgrade events, this exited application will no longer be mistakenly identified as a target process requiring coordination.

[0100] Operation S110 may include operation S730.

[0101] In operation S730 , each target process is confirmed based on each saved registration information.

[0102] Specifically, when executing operation S110, i.e., confirming target processes requiring coordination in response to receiving a driver upgrade instruction for a target processing unit, the driver upgrade process or related management module will review and traverse all currently saved and unregistered "registration information." Each valid registration information uniquely corresponds to a currently running target process that uses or claims to use the target processing unit. By parsing the process identifiers (e.g., process IDs) and possible target processing unit information contained in these registration information, an accurate list of all target processes affected by the driver upgrade can be constructed. These confirmed target processes will then become the targets of subsequent operations (such as the transmission of the pause instruction in operation S120).

[0103] Figure 8 Another flowchart of the driver upgrade method according to an embodiment of the present disclosure is schematically shown.

[0104] like Figure 8 As shown, based on the above embodiment, operation S130 may include operations S810 to S820.

[0105] In operation S810, usage information of the first target function module corresponding to each target process in the target processing unit is released.

[0106] The usage information of the first target functional module in the target processing unit may be a handle, descriptor, context or other form of reference obtained and held by the first target functional module when interacting with the driver or hardware of the target processing unit on behalf of its host target process, and used to identify and manage GPU resource access.

[0107] Specifically, before the driver of the target processing unit actually performs the uninstall operation, in order to ensure that the driver kernel module can be removed cleanly and without conflict, it is necessary to ensure that all processes currently holding the driver kernel module handle or the resource references of the target processing unit associated with it have released these handles or references. This operation S810 is aimed at this requirement. For each process identified as a target process, its corresponding first target functional module will execute a resource release routine. This routine is responsible for closing or releasing all "usage information" related to the current driver to be upgraded that it opened or obtained during the interaction between the target process and the target processing unit. This may include closing the device file descriptor opened by the target processing unit driver, releasing the device context handle obtained through the driver API of the target processing unit, or releasing the direct reference count of the target processing unit kernel module. Through this operation, the target process's occupation of the old driver kernel module is cleared, creating conditions for the smooth uninstallation of the subsequent driver module.

[0108] For example, assume that a target process interacts with a GPU through its corresponding first target functional module. During the interaction, the call proxy layer may open the device file representing the GPU through an operating system call and obtain a file descriptor. In addition, it may also create and hold a GPU context handle through the API provided by the GPU manufacturer (for example, a function to initialize the GPU context). In the GPU driver upgrade process, before the old GPU driver kernel module is ready to be uninstalled, operation S810 is triggered. At this time, its resource release logic is executed: the operating system function is called to close the previously opened GPU device file descriptor, and the corresponding function in the GPU manufacturer's API is called to release the GPU context handle it holds. After completing these operations, the first target functional module no longer holds a direct reference to or occupies the old GPU driver kernel module, so that the kernel module can be safely uninstalled.

[0109] In operation S820, a driver of the target processing unit is upgraded according to the driver upgrade request.

[0110] Specifically, after the first target functional modules corresponding to all target processes have successfully released their usage information within the target processing unit, i.e., after confirming that no active processes are directly occupying the driver kernel module resources of the target processing unit to be upgraded, the actual driver upgrade operation can be safely performed. This operation, based on the driver version information and package location specified in the previously received "Driver Upgrade Request," typically includes the following steps: first, uninstalling the old version of the driver module for the target processing unit currently loaded in the operating system kernel; second, installing the new version of the driver file to a designated system directory; and finally, loading the new version of the driver kernel module for the target processing unit into the operating system kernel and completing its initialization. If the standard uninstall process is hindered by residual references (even though S810 has been executed, other references not managed by this solution may still exist), a forced uninstall parameter can be used to remove the old driver module according to a preset policy, while ensuring data security.

[0111] For example, after the call proxy layer of all target processes has closed the GPU device file descriptors and released the GPU context handle, the driver upgrade process begins to upgrade the GPU driver. First, it uses standard kernel module management commands to uninstall the old GPU driver kernel module. Because all target processes managed by this solution have released the relevant handles, the probability of this uninstallation being successful is greatly increased. If the uninstallation is successful, the driver upgrade process then runs the installation script for the new driver version (for example, an installer provided by the GPU hardware vendor). This script copies the new driver files (such as library files, firmware, and configuration files) to the correct system path and compiles and installs the new GPU driver kernel module. Finally, the driver upgrade process uses kernel module management commands to load and initialize the new GPU driver kernel module. At this point, the GPU driver upgrade is complete.

[0112] According to the embodiment of the present disclosure, by ensuring that the first target functional modules corresponding to all target processes release their usage information (such as handles and descriptors) in the GPU before upgrading the driver kernel module, the possibility of successfully uninstalling the GPU driver kernel module is improved, and the key problem of driver upgrade failure or the need to forcibly restart the system due to the process holding the kernel module handle is avoided.

[0113] According to an embodiment of the present disclosure, each first-target functional module can be integrated into a call proxy layer. The call proxy layer, typically implemented as a dynamic link library (DLL) or shared object (SO), serves as the key middleware and controllable interface between the target process and the native driver of the target processing unit. By encapsulating and exposing a series of first-target functional modules (i.e., proxy functions) corresponding to the GPU native API functions (i.e., second-target functional modules), the call proxy layer can uniformly intercept and manage all call requests from the target process to the GPU. The call proxy layer has built-in operational logic required to perform the driver upgrade coordination proposed in this disclosure. This logic includes, but is not limited to: responding to control signals issued by the driver upgrade process, controlling the first-target functional modules within it to enter a dormant or working state to achieve pause and resume of instruction transmission, coordinating the backup and recovery of GPU target data, managing the registration and deregistration information of the target process, and releasing resource handles to the GPU driver kernel module at appropriate times.

[0114] Figure 9 The following schematically shows a block diagram of a driver upgrade process according to an embodiment of the present disclosure.

[0115] like Figure 9 As shown, this figure takes the GPU driver upgrade as an example and shows the changes over time in the activities of two processes that are carried out in parallel but coordinated with each other at key stages: the "driver upgrade process" on the top and the "GPU service process" on the bottom.

[0116] The driver upgrade process mainly goes through the following two consecutive stages during its life cycle of executing the driver upgrade task:

[0117] File Installation Phase: During this phase, the driver upgrade process pre-deploys and installs the new driver's related files. This phase is a preparatory step for the driver upgrade, such as copying the new driver files to the system directory, but does not yet actually affect the running kernel driver module.

[0118] Kernel Upgrade Phase: After the file installation is complete, the driver upgrade process enters the kernel upgrade phase. This phase is the core and key step of the driver upgrade, typically involving uninstalling the old version of the GPU driver module currently loaded in the operating system kernel and subsequently loading the new version of the GPU driver kernel module. This phase corresponds to the core actions of operation S130 (upgrading the driver of the target processing unit) and operation S820 (upgrading the driver of the target processing unit according to the driver upgrade request) in the embodiments of this disclosure.

[0119] At the same time, the GPU service process's status dynamically adjusts based on the driver upgrade process to ensure a smooth upgrade. This progress is achieved through the following successive phases: GPU Process Operation (Initial Phase): Before the driver upgrade process begins, the GPU service process operates normally, executing its intended tasks using the target processing unit. This phase corresponds to the target process's normal operating state without interference.

[0120] GPU data backup phase: When the "driver upgrade process" starts to execute the "file installation phase", or after this phase starts and before the "kernel upgrade phase" starts, the GPU service process (through the coordination of the first target function module in its internal integration or associated call proxy layer) will start and execute the "GPU data backup" operation. This operation saves the target data associated with the GPU service process in the GPU to the host memory or other secure storage location, corresponding to Figure 6 In the illustrated embodiment, operation S610 (saving target data associated with each target process in the target processing unit) is crucial for ensuring that data is not lost when the kernel module is subsequently reloaded.

[0121] GPU process suspension phase: After the "GPU data backup" operation is completed and when the "driver upgrade process" is about to start or has already started the "kernel upgrade phase", the GPU service process enters the "GPU process suspension" state. In this state, the GPU service process's instruction transmission to the GPU is suspended. This corresponds to the present disclosure Figure 1 Operation S120 in the illustrated embodiment (suspending the instruction transmission process of each target process to the target processing unit), and Figure 3In the embodiment shown, operation S310 (controlling the first target functional module to enter a dormant state to prevent the first target functional module from calling the second target functional module in the target processing unit) and Figure 4 In the embodiment shown, the process of operation S410 (loop detection of whether the driver of the target processing unit is upgraded) is performed. At the same time, before or at the beginning of this stage, the present disclosure will also be executed. Figure 8 In the illustrated embodiment, operation S810 (releasing usage information for the first target functional module corresponding to each target process in the target processing unit) ensures that the old driver kernel module can be successfully uninstalled. This "GPU process suspension" phase overlaps with the "kernel upgrade phase" of the "driver upgrade process," ensuring that the GPU service process does not perform any operations on the GPU during the critical period when the kernel module is being replaced.

[0122] GPU process running (recovery phase): When the "driver upgrade process" successfully completes the "kernel upgrade phase" (i.e., the new driver kernel module has been loaded and initialized), the GPU service process recovers from the "GPU process suspended" state to the normal "GPU process running" state. This recovery process first includes the following steps: Figure 6 In the illustrated embodiment, operation S620 (restore the data associated with each target process in the target processing unit based on the target data) restores the previously backed-up data to the GPU (this step is not explicitly separated in the figure, but is implicitly included between the end of "GPU process suspension" and the resumption of "GPU process running" or at the beginning of the resumption). Subsequently, the transmission of instructions from each target process to the target processing unit is resumed, which corresponds to the present disclosure. Figure 2 Operation S210 in the illustrated embodiment (response to completion of the driver upgrade, resuming the instruction transmission process of each target process to the target processing unit), and Figure 5 In the illustrated embodiment, operation S510 is performed (in response to completion of the driver upgrade, controlling the first target functional module to enter a working state).

[0123] Figure 10 The figure schematically shows a timing diagram of driver upgrade according to an embodiment of the present disclosure.

[0124] like Figure 10 As shown, the figure takes the GPU driver upgrade when the process calls the CUDA function in the GPU as an example, and shows the interaction timing between the GPU process, CUDA call agent and driver upgrade process in the upgrade process.

[0125] As shown in the figure, the driver upgrade process first initiates upgrade preparations and sends a "Prepare driver upgrade, notify all GPU call agents" instruction to all registered CUDA call agents. This step corresponds to the initial phase of receiving the driver upgrade request and identifying the target process to be coordinated (interacting through its CUDA call agent).

[0126] At some point, the GPU process, following its normal business logic, initiates a CUDA call request (e.g., a CUDA API function call) to the CUDA call agent. This call is first intercepted by the corresponding first target function module in the CUDA call agent.

[0127] After receiving the "CUDA call" from the "GPU process", the "CUDA call agent" performs the operation of "pausing the CUDA call and backing up the GPU data to the host" in combination with the "prepare driver upgrade" notification it has received. Specifically, the first target function module does not immediately forward this CUDA call to the underlying GPU driver (i.e., the second target function module), but instead puts it into a dormant state (as described in the present disclosure). Figure 3 In the embodiment shown in S310), the GPU target data backup process is started at the same time, and the relevant data in the GPU display memory is saved to the host memory (as disclosed in the present invention). Figure 6 S610 in the illustrated embodiment)

[0128] After call suspension and data backup are complete (or at least data backup has been initiated and calls have been reliably suspended), the CUDA call agent sends a feedback message to the driver upgrade process, notifying the upgrade process to receive the signal and suspend calls. This step ensures that the driver upgrade process is informed that all CUDA call agents are ready for subsequent kernel upgrade operations. This corresponds to the statement in this disclosure document that "the upgrade process waits for feedback from all registered call agent layers."

[0129] After confirming that all call agents have been paused (for example, after receiving feedback from all relevant CUDA call agents indicating that they have paused their calls to CUDA and completed necessary preparations), the "driver upgrade process" begins to perform the core "upgrade kernel module" operation. This operation includes unloading the old GPU driver kernel module and loading the new GPU driver kernel module, corresponding to the present disclosure. Figure 8 In the illustrated embodiment, the driver upgrade action is performed at operation S820 , and the kernel module handle is released before that at S810 .

[0130] After the new GPU driver kernel module is successfully loaded and initialized, the "driver upgrade process" sends a message to the "CUDA call agent" that "kernel module upgrade is complete, notify the call agent". This message serves as a signal that the driver upgrade is complete, corresponding to the present disclosure Figure 4 The stopping condition of the loop detection in S410 in the illustrated embodiment.

[0131] After receiving the notification of "kernel module upgrade completed", the "CUDA call agent" performs the operation of "restoring GPU data and rebuilding variables pointing to execute CUDA calls". Specifically, it first restores the GPU data previously backed up in the host memory to the GPU memory (as disclosed in this disclosure). Figure 6 S620 in the embodiment shown), and it may be necessary to adjust the mapping relationship of the GPU memory address according to the new driver environment (rebuild the variable pointing). Subsequently, the first target functional module is restored from the dormant state to the working state (as disclosed in the present invention). Figure 5 ), and actually forwards the previously suspended “CUDA call” from the “GPU process” to the newly loaded GPU driver (the second target functional module) for execution.

[0132] Figure 11 The block diagram schematically shows a driver upgrade apparatus according to an embodiment of the present disclosure.

[0133] like Figure 11 As shown, the driver upgrading apparatus 1100 may include a first confirmation module 1110 , a first suspension module 1120 , and a first upgrading module 1130 .

[0134] The first confirmation module 1110 is used to confirm the target process in response to receiving the driver upgrade instruction for the target processing unit, where the target process is a process that executes the target task based on the target processing unit. In some embodiments, the first confirmation module 1110 can be used to perform operation S110 in the above-mentioned driver upgrade method, which is not described in detail here.

[0135] The first suspension module 1120 is used to suspend the instruction transmission process of each target process to the target processing unit to suspend the executed target task. In some embodiments, the first suspension module 1120 can be used to perform operation S120 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0136] The first upgrade module 1130 is used to respond to the pause of each instruction transmission process and upgrade the driver of the target processing unit based on the driver upgrade request. In some embodiments, the first upgrade module 1130 can be used to perform operation S130 in the above driver upgrade method, which will not be described in detail here.

[0137] According to an embodiment of the present disclosure, the driver upgrading apparatus may further include a first recovery module.

[0138] The first recovery module is configured to, in response to the completion of the driver upgrade, resume the instruction transmission process of each target process to the target processing unit, so that each target process continues to execute the target task based on the target processing unit. In some embodiments, the first recovery module can be used to perform operation S210 in the driver upgrade method described above, which is not further described here.

[0139] According to an embodiment of the present disclosure, the first pause module may include a first control module.

[0140] The first control module is used to control the first target function module to enter a dormant state to prevent the first target function module from calling the second target function module in the target processing unit. In some embodiments, the first control module can be used to perform operation S310 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0141] According to an embodiment of the present disclosure, the first pause module may further include a cycle detection module.

[0142] The loop detection module is configured to control the first target functional module to execute the following functions until a stop condition is satisfied: loop detection of whether the driver of the target processing unit is completely upgraded; the stop condition includes: the driver upgrade of the target processing unit is completely upgraded. In some embodiments, the loop detection module can be used to execute operation S410 in the driver upgrade method described above, which is not further described here.

[0143] According to an embodiment of the present disclosure, the first recovery module may include a second control module.

[0144] The second control module is configured to, in response to the completion of the driver upgrade, control the first target functional module to enter a working state, causing the first target functional module to call the corresponding second target functional module in the target processing unit to continue executing the target task. In some embodiments, the second control module can be configured to execute operation S510 in the driver upgrade method described above, which is not further described herein.

[0145] According to an embodiment of the present disclosure, the driver upgrade apparatus may further include a first saving module and a second restoring module.

[0146] The first saving module is used to save the target data associated with each target process in the target processing unit. In some embodiments, the first saving module can be used to perform operation S610 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0147] The second recovery module is used to recover data associated with each target process in the target processing unit based on the target data. In some embodiments, the second recovery module can be used to perform operation S620 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0148] According to an embodiment of the present disclosure, the driver upgrade apparatus may further include a registration module and a deregistration module, and the first confirmation module may include a second confirmation module.

[0149] The registration module is used to generate and save the registration information of the target process in response to the creation of the target process. In some embodiments, the registration module can be used to perform operation S710 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0150] The deregistration module is used to delete the registration information corresponding to the target process in response to the deregistration of the target process. In some embodiments, the deregistration module can be used to perform operation S720 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0151] The second confirmation module is used to confirm each target process based on each saved registration information. In some embodiments, the second confirmation module can be used to perform operation S730 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0152] According to an embodiment of the present disclosure, the first upgrading module may include a releasing module and a second upgrading module.

[0153] The release module is used to release the usage information of the first target function module corresponding to each target process in the target processing unit. In some embodiments, the release module can be used to perform operation S810 in the above-mentioned driver upgrade method, which will not be described in detail here.

[0154] The second upgrade module is used to upgrade the driver of the target processing unit according to the driver upgrade request. In some embodiments, the second upgrade module can be used to perform operation S820 in the above driver upgrade method, which will not be described in detail here.

[0155] According to the embodiments of the present invention, any number of modules, sub-modules, units, and sub-units, or at least part of the functions of any number of them, can be implemented in one module. According to the embodiments of the present invention, any one or more of the modules, sub-modules, units, and sub-units can be split into multiple modules for implementation. According to the embodiments of the present invention, any one or more of the modules, sub-modules, units, and sub-units can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented by hardware or firmware in any other reasonable way of integrating or packaging the circuit, or can be implemented in any one of the three implementation methods of software, hardware, and firmware, or in any appropriate combination of any of them. Alternatively, according to the embodiments of the present invention, one or more of the modules, sub-modules, units, and sub-units can be at least partially implemented as a computer program module, which can perform the corresponding functions when the computer program module is executed.

[0156] For example, any multiple of the first confirmation module 1110, the first suspension module 1120, and the first upgrade module 1130 can be combined into a single module / unit / sub-unit, or any one of these modules / units / sub-units can be split into multiple modules / units / sub-units. Alternatively, at least part of the functionality of one or more of these modules / units / sub-units can be combined with at least part of the functionality of other modules / units / sub-units and implemented in a single module / unit / sub-unit. According to an embodiment of the present disclosure, at least one of the first confirmation module 1110, the first suspension module 1120, and the first upgrade module 1130 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or can be implemented in any one of software, hardware, and firmware, or any suitable combination of any of these. Alternatively, at least one of the first confirmation module 1110 , the first suspension module 1120 , and the first upgrade module 1130 may be at least partially implemented as a computer program module, and when the computer program module is executed, the corresponding function may be executed.

[0157] It should be noted that the data processing system part in the embodiments of the present disclosure corresponds to the data processing method part in the embodiments of the present disclosure. The description of the data processing system part specifically refers to the data processing method part and will not be repeated here.

[0158] Figure 12A block diagram of an electronic device suitable for implementing the above-described method according to an embodiment of the present disclosure is schematically shown. Figure 12 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0159] like Figure 12 As shown, the electronic device 1200 according to an embodiment of the present disclosure includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage portion 1208 into a random access memory (RAM) 1203. The processor 1201 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0160] Various programs and data required for the operation of the electronic device 1200 are stored in the RAM 1203. The processor 1201, the ROM 1202, and the RAM 1203 are connected to each other via a bus 1204. The processor 1201 performs various operations of the method flow according to the embodiment of the present disclosure by executing the programs in the ROM 1202 and / or the RAM 1203. It should be noted that the programs may also be stored in one or more memories other than the ROM 1202 and the RAM 1203. The processor 1201 may also perform various operations of the method flow according to the embodiment of the present disclosure by executing the programs stored in the one or more memories.

[0161] According to an embodiment of the present disclosure, electronic device 1200 may further include an input / output (I / O) interface 1205, which is also connected to bus 1204. Electronic device 1200 may also include one or more of the following components connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 1208 including a hard disk; and a communication section 1209 including a network interface card such as a LAN card or modem. Communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 1210 as needed, so that computer programs read from the removable media can be installed into storage section 1208 as needed.

[0162] According to an embodiment of the present disclosure, the electronic device 1200 may further include a target processing unit 1212, which may be one or more dedicated hardware processing components for efficiently executing computing tasks of a specific type or field, so as to assist or enhance the processing capabilities of the main processor (e.g., processor 1201) in the electronic device 1200. By transferring specific computationally intensive or highly parallel workloads to the target processing unit 1212, the overall system performance and energy efficiency can be significantly improved. The target processing unit 1212 typically communicates and exchanges data with the processor 1201 and system memory (e.g., RAM 1203) through a system bus (e.g., an extension of bus 1204 or a dedicated high-speed interface, not shown separately) to receive instructions, access data, and return processing results. Specifically, the target processing unit 1212 may be, for example, one or more of a graphics processing unit (GPU), a tensor processing unit (TPU), and a neural network processing unit (NPU). It should be noted that, Figure 12 The GPU is schematically shown as an example of the target processing unit 1212 , which does not mean that the target processing unit 1212 can only be a graphics processing unit (GPU).

[0163] According to an embodiment of the present disclosure, the method flow according to an embodiment of the present disclosure can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1209, and / or installed from the removable medium 1211. When the computer program is executed by the processor 1201, the above-mentioned functions defined in the system of the embodiment of the present disclosure are executed. According to an embodiment of the present disclosure, the system, device, apparatus, module, unit, etc. described above can be implemented by a computer program module.

[0164] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when executed, implements the method according to the embodiments of the present disclosure.

[0165] According to embodiments of the present disclosure, a computer-readable storage medium may be a non-volatile computer-readable storage medium. Examples include, but are not limited to, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0166] For example, according to an embodiment of the present disclosure, the computer-readable storage medium may include the ROM 1202 and / or the RAM 1203 described above and / or one or more memories other than the ROM 1202 and the RAM 1203 .

[0167] An embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method provided by the embodiment of the present disclosure. When the computer program product runs on an electronic device, the program code is used to enable the electronic device to implement the control method provided by the embodiment of the present disclosure.

[0168] When the computer program is executed by the processor 1201, the above functions defined in the system / device of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0169] In one embodiment, the computer program may be based on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of a signal on a network medium, and downloaded and installed through the communication part 1209, and / or installed from a removable medium 1211. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above. According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure may be written in any combination of one or more programming languages. Specifically, these computer programs may be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include but are not limited to languages ​​such as Java, C++, Python, "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. Where a remote computing device is involved, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., through the Internet using an Internet service provider).

[0170] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, which contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the boxes can also occur in an order different from that marked in the accompanying drawings. For example, two boxes shown in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, as well as the combination of boxes in the block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions. It will be understood by those skilled in the art that the features described in the various embodiments of the present disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present disclosure. In particular, without departing from the spirit and teachings of the present disclosure, the features described in the various embodiments of the present disclosure may be combined and / or coupled in various ways, and all of these combinations and / or couplings fall within the scope of the present disclosure.

[0171] The above describes the embodiments of the present disclosure. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present disclosure, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A driver upgrade method, comprising: In response to receiving a driver upgrade instruction for a target processing unit, confirming a target process, wherein the target process is a process that executes a target task based on the target processing unit; pausing the instruction transmission process of each of the target processes to the target processing unit to suspend the execution of the target task; In response to the suspension of each of the instruction transmission processes, the driver of the target processing unit is upgraded based on the driver upgrade request.

2. The method according to claim 1, further comprising: In response to completion of the driver upgrade, the instruction transmission process of each target process to the target processing unit is resumed, so that each target process continues to execute the target task based on the target processing unit.

3. The method according to claim 1 or 2, wherein the target process executes the target task based on the target processing unit, comprising: A target instruction is sent to a first target functional module based on the target process, so that the first target functional module calls a corresponding second target functional module in the target processing unit to execute the target task.

4. The method according to claim 3, wherein suspending the instruction transmission process of each target process to the target processing unit comprises: The first target functional module is controlled to enter a dormant state to prevent the first target functional module from calling a second target functional module in the target processing unit.

5. The method according to claim 4, after controlling the first target functional module to enter a dormant state, further comprising: Control the first target function module to perform the following functions until a stop condition is met: Circularly detecting whether the driver of the target processing unit is upgraded; The stop condition includes: the driver upgrade of the target processing unit is completed.

6. The method according to claim 2 or 4, wherein, in response to completion of the driver upgrade, resuming the instruction transmission process of each target process to the target processing unit so that each target process continues to execute the target task based on the target processing unit, comprises: In response to the completion of the driver upgrade, the first target function module is controlled to enter a working state, so that the first target function module calls the corresponding second target function module in the target processing unit to continue executing the target task.

7. The method according to claim 2, before upgrading the driver of the target processing unit, further comprising: Saving target data associated with each target process in the target processing unit; Before resuming the instruction transmission process of each target process to the target processing unit, the method further includes: Based on the target data, data associated with each target process in the target processing unit is restored.

8. The method according to claim 1, further comprising: In response to the creation of the target process, generating and saving registration information of the target process; In response to the deregistration of the target process, deleting the registration information corresponding to the target process; The target confirmation process includes: Based on the saved registration information, each target process is confirmed.

9. The method according to claim 3, wherein the upgrading the driver of the target processing unit comprises: releasing usage information of the first target function module corresponding to each target process in the target processing unit; The driver of the target processing unit is upgraded according to the driver upgrade request.

10. An electronic device comprising: A target processing unit, configured to execute a target task; at least one processor; as well as a memory connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the following operations: in response to receiving a driver upgrade instruction for a target processing unit, confirming a target process, wherein the target process is a process that executes a target task based on the target processing unit; pausing the instruction transmission process of each target process to the target processing unit to suspend the executed target task; and in response to the suspension of each instruction transmission process, upgrading the driver of the target processing unit based on the driver upgrade request.

Images