Processor calling method and apparatus, and device
By adding a fusion layer in the computing device, using the sum of the video memory capacity of multiple processors to form a virtual processor, the problem of insufficient video memory capacity of the processor is solved, and the resource utilization rate and universality of computing devices are improved.
Patent Information
- Application Number
- PCT/IB2025/050506
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-29
- Filing Date
- 2025-01-17
- Publication Date
- 2025-08-07
AI Technical Summary
The existing processors have small memory capacity, which is difficult to meet the needs of emerging large-scale AI computing tasks, resulting in low resource utilization of multiple processors in computing devices.
By adding a fusion layer to the computing device, it is determined that the sum of the video memory capacity of multiple processors is the virtual video memory capacity of the virtual processor, and the fusion layer intercepts the call request of the target application, and calls multiple processors to process the request, realizing the call of the virtual processor.
It improves the resource utilization rate of multiple processors in the computing device, enhances the universality of the computing device, avoids the splitting of computing tasks, and improves the computing efficiency.
Smart Images

Figure IB2025050506_07082025_PF_FP_ABST
Abstract
Description
[0001] This disclosure claims priority to Chinese patent application number 202410124323.5, filed with the China Patent Office on January 29, 2024, entitled "Processor Calling Method, Apparatus, and Device," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of computers, and more particularly to a method, apparatus, and device for calling a processor. Background: Processors can perform high-performance computing tasks such as graphics rendering and artificial intelligence (AI) model calculations. The processor's video memory can store real-time data and calculation results during computing tasks. Currently, with the development of AI models, the amount of real-time data used in AI model calculations is increasing. Single model calculation tasks are placing increasing demands on the processor's video memory capacity. However, the video memory capacity of most current processors is relatively small, making it difficult to apply existing processors to emerging large-scale AI computing tasks, resulting in low resource utilization for multiple processors in computing devices. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a processor invocation method, apparatus, and device for improving resource utilization of multiple processors in a computing device. In a first aspect, embodiments of the present disclosure provide a processor invocation method, applied to a computing device equipped with multiple processors, each corresponding to a virtual processor. The method comprises: sending virtual processor information of the virtual processor to a target application via a fusion layer, the virtual processor information including the number of virtual processors and the virtual memory capacity corresponding to the virtual processor, the virtual memory capacity being the sum of the memory capacities of the multiple processors; intercepting, via the fusion layer, a call request from the target application for the virtual processor, and invoking the multiple processors to process the call request. In one possible implementation, sending the virtual processor information of the virtual processor to the target application via the fusion layer includes: intercepting, via the fusion layer, an information acquisition request from the target application for requesting processor information of the multiple processors; determining the virtual processor information based on the information acquisition request, and sending the virtual processor information to the target application. In one possible implementation, determining the virtual processor information according to the information acquisition request includes: acquiring processor information of the multiple processors in the computing device according to the information acquisition request, the processor information including video memory capacity of video memory in the processors; determining the virtual video memory capacity according to the processor information; and determining the virtual processor information according to the virtual video memory capacity.In one possible implementation, invoking the multiple processors to process the call request includes: determining a call type of the call request, where the call type includes at least one of the following: an initialization type, a video memory allocation type, an upload data type, or an execution type; and invoking the multiple processors to process the call request based on the call type. In another possible implementation, determining the call type of the call request includes: determining an application programming interface (API) invoked by the call request; and determining the call type based on the API. In another possible implementation, the call type is the initialization type; and invoking the multiple processors to process the call request based on the call type includes: initializing each processor based on the initialization type to obtain a runtime handle corresponding to each processor; generating a virtual runtime handle based on the runtime handle corresponding to each processor; and sending the virtual runtime handle to the target application, where the virtual runtime handle is used by the target application to call the multiple processors. In one possible implementation, the call type is the video memory allocation type, and the call request includes the target video memory capacity requested for allocation. Based on the call type, invoking the multiple processors to process the call request includes: determining at least one storage space in the multiple processors based on the target video memory capacity, where the sum of the sizes of the at least one storage space is the target video memory capacity; generating a virtual address based on the physical address of the at least one storage space, and sending the virtual address to the target application. In another possible implementation, the call type is the upload data type, and the call request includes the target data to be uploaded. Based on the call type, invoking the multiple processors to process the call request includes: determining a virtual address allocated for the target application; determining at least one physical address corresponding to the virtual address, where the at least one physical address is the address of at least one storage space in multiple video memories of the multiple processors; and storing the target data in the at least one storage space based on the at least one physical address.In one possible embodiment, the call type is the execution type, and the call request includes function parameters of a to-be-called function. Based on the call type, calling the multiple processors to process the call request includes: determining, based on the function parameters, at least one first processor among the multiple processors, wherein the first processor has data to be processed corresponding to the to-be-called function stored in its video memory; and calling the at least one first processor to execute the to-be-called function based on a runtime handle of the at least one first processor and the data to be processed, thereby processing the call request. In one possible embodiment, the number of the at least one first processors is greater than one; calling the at least one first processor to execute the to-be-called function based on the runtime handle of the at least one first processor and the data to be processed, thereby processing the call request, includes: determining a target processor and a migration processor among the at least one first processor; migrating the data to be processed in the migration processor to the target processor; and calling the target processor based on the runtime handle of the target processor, such that the target processor processes the data to be processed using the to-be-called function to obtain a processing result. In one possible implementation, the method further includes: obtaining the processing result from the video memory of the target processor, and sending the processing result to the target application. In one possible implementation, the method further includes: releasing the video memory in the multiple processors allocated for the target application. In a second aspect, an embodiment of the present disclosure provides a processor calling device, which is applied to a computing device, wherein the computing device is provided with multiple processors, and the multiple processors correspond to virtual processors. The device includes: a sending module, an interception module, and a calling module, wherein the sending module is used to send virtual processor information of the virtual processor to the target application through a fusion layer, wherein the virtual processor information includes the number of virtual processors and the virtual video memory capacity corresponding to the virtual processor, and the virtual video memory capacity is the sum of the video memory capacities of the multiple processors; the interception module is used to intercept the target application's call request for the virtual processor through the fusion layer; and the calling module is used to call the multiple processors to process the call request. In a possible implementation, the sending module is specifically configured to intercept, through the fusion layer, an information acquisition request of the target application, where the information acquisition request is used to request processor information of the multiple processors; determine the virtual processor information based on the information acquisition request, and send the virtual processor information to the target application.In one possible implementation, the sending module is specifically configured to, based on the information acquisition request, obtain processor information of the multiple processors in the computing device, the processor information including the video memory capacity of the video memory in the processors; determine the virtual video memory capacity based on the processor information; and determine the virtual processor information based on the virtual video memory capacity. In one possible implementation, the calling module is specifically configured to determine a call type of the call request, the call type including at least one of the following: initialization type, video memory allocation type, upload data type, or execution type; and based on the call type, call the multiple processors to process the call request. In one possible implementation, the calling module is specifically configured to determine an application programming interface (API) invoked by the call request; and determine the call type based on the API. In one possible implementation, the call type is the initialization type; the calling module is specifically configured to, based on the initialization type, initialize each processor to obtain a runtime handle corresponding to each processor; generate a virtual runtime handle based on the runtime handle corresponding to each processor; and send the virtual runtime handle to the target application, where the virtual runtime handle is used by the target application to call the multiple processors. In another possible implementation, the call type is the video memory allocation type, and the call request includes a target video memory capacity to be allocated. The calling module is specifically configured to, based on the target video memory capacity, determine at least one storage space in the multiple processors, where the sum of the sizes of the at least one storage space is the target video memory capacity; generate a virtual address based on the physical address of the at least one storage space, and send the virtual address to the target application. In one possible implementation, the call type is the upload data type, and the call request includes target data to be uploaded; the calling module is specifically configured to: determine a virtual address allocated to the target application; determine at least one physical address corresponding to the virtual address, where the at least one physical address is an address of at least one storage space in multiple video memories of the multiple processors; and store the target data in the at least one storage space according to the at least one physical address.In one possible implementation, the call type is the execution type, and the call request includes function parameters of the function to be called. The calling module is specifically configured to, based on the function parameters, determine at least one first processor among the multiple processors, wherein the video memory of the first processor stores the to-be-called data corresponding to the function to be called. Based on the runtime handle of the at least one first processor and the to-be-processed data, call the at least one first processor to execute the function to be called, thereby processing the call request. In one possible implementation, the number of the at least one first processor is greater than one. The calling module is specifically configured to, among the at least one first processor, determine a target processor and a migration processor; migrate the to-be-processed data in the migration processor to the target processor; and call the target processor based on the runtime handle of the target processor, so that the target processor processes the to-be-processed data using the function to be called to obtain a processing result. In one possible implementation, the sending module is further configured to retrieve the processing result from the video memory of the target processor and send the processing result to the target application. In one possible implementation, the apparatus further includes a release module configured to release video memory allocated to the target application in the multiple processors. In a third aspect, embodiments of the present disclosure provide an electronic device comprising: a memory and a processor; the memory storing computer-executable instructions; and the processor executing the computer-executable instructions stored in the memory, causing the processor to perform any of the methods described in the first aspect. In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by the processor, implement any of the methods described in the first aspect. In a fifth aspect, embodiments of the present disclosure provide a computer program product comprising a computer program, which, when executed by the processor, implements any of the methods described in the first aspect. Embodiments of the present disclosure provide a processor invocation method, apparatus, and device. The computing device can send virtual processor information of a virtual processor to a target application via a fusion layer, intercept the target application's call request for the virtual processor via the fusion layer, and invoke multiple processors to process the call request. Because the virtual video memory capacity can be the sum of the video memory capacities of multiple processors in a computing device, that is, the virtual video memory capacity is large, the target application can directly call the virtual processor to perform computing tasks without splitting the computing tasks. This avoids splitting computing tasks according to specific computing scenarios and improves the versatility of computing.Furthermore, in the above method, multiple processors in the computing device can be used to process the target application's call request for a virtual processor, thereby fully utilizing the multiple processors in the computing device and improving resource utilization of the multiple processors in the computing device. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and are not intended to unduly limit the present disclosure. In the accompanying drawings: Figure 1 is a structural diagram of a computing device provided by an exemplary embodiment of the present disclosure; Figure 2 is a flow diagram of a method for calling a processor provided by an exemplary embodiment of the present disclosure; Figure 3 is a structural diagram of another computing device provided by an exemplary embodiment of the present disclosure; Figure 4 is a structural diagram of a system software layer provided by an exemplary embodiment of the present disclosure; Figure 5 is a flow diagram of another method for calling a processor provided by an exemplary embodiment of the present disclosure; Figure 6 is a schematic diagram of a virtual runtime generation process provided by an exemplary embodiment of the present disclosure; Figure 7 is a schematic diagram of a process for establishing an address mapping relationship provided by an exemplary embodiment of the present disclosure; Figure 8 is a schematic diagram of a process for storing target data provided by an exemplary embodiment of the present disclosure; Figure 9 is a schematic diagram of a process for executing a function provided by an exemplary embodiment of the present disclosure; Figure 10 is a flow diagram of another method for calling a processor provided by an exemplary embodiment of the present disclosure; Figure 11 is a structural diagram of a processor calling device provided by an exemplary embodiment of the present disclosure; Figure 12 is a structural diagram of another processor calling device provided by an exemplary embodiment of the present disclosure; Figure 13 is a structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS: It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) referred to in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with relevant laws, regulations, and standards, and corresponding operation portals are provided for users to choose to authorize or reject. To further clarify the objectives, technical solutions, and advantages of this disclosure, the technical solutions of this disclosure will be described clearly and completely below in conjunction with specific embodiments of this disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of this disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure. To facilitate understanding, the technical terms used in the embodiments of this disclosure are first explained.A graphics processing unit (GPU) is a hardware device used for high-performance computing such as graphics rendering and artificial intelligence (AI) calculations. Video memory refers to the dedicated volatile memory within the GPU. Video memory can be used to store real-time data and calculation results processed by the GPU. The size of the video memory determines the GPU's application scenarios. To facilitate understanding, the computing device involved in the embodiments of the present disclosure is described below with reference to Figure 1. Figure 1 is a schematic diagram of the structure of a computing device provided in an exemplary embodiment of the present disclosure. Referring to Figure 1, the computing device. In [1], m is an integer greater than or equal to 1, and n is an integer greater than or equal to 2. For example, the application can be a GPU application, and the processor can be a GPU. The computing device can be any electronic device having a structure similar to that shown in Figure 1. For example, the computing device can be a server, etc. The embodiments of this disclosure do not limit the specific type and structure of the computing device. The computing device can include more or less software and more or less hardware than shown. The application can call the processor to perform the application's computing tasks. For example, the computing tasks can include image processing tasks and AI model computing tasks. Specifically, before executing the computing task, the computing device can store the computational data required for the computing task in the processor's video memory. The processor can complete the computing task based on the computational data in the video memory and temporarily store the computational results in the video memory. Currently, with the development of AI models, the amount of computational data required for AI model calculations is continuously increasing. The demand for video memory capacity for a single AI model computing task is increasing. However, the development and iteration of processor hardware significantly lags behind the growth of AI models. Existing processors with smaller graphics memory capacities are underutilized, resulting in low resource utilization for multiple processors in computing devices. Related technologies have been used to improve resource utilization for multiple processors in computing devices by splitting a single application's computing task into multiple subtasks and assigning these subtasks to different processors, allowing multiple processors to complete the single computing task. In this approach, each processor's graphics memory only needs to store the computational data required for the corresponding subtask, not all the computational data required for the task. This allows even processors with smaller graphics memory capacities to be utilized. However, the methods for splitting computing tasks vary between applications. In actual implementation, each application needs to analyze and split specific computing tasks based on their specific computing scenarios, making it impossible to provide a universal processing method for all computing tasks. This results in poor versatility for these approaches. To address this issue, embodiments of the present disclosure incorporate a fusion layer into the computing device. The fusion layer can determine the sum of the video memory capacities of multiple processors in a computing device as the virtual video memory capacity of a virtual processor. It can also send this virtual video memory capacity to applications, allowing them to determine the presence of a processor (virtual processor) with a larger video memory capacity in the computing device and call upon the virtual processor to perform computing tasks. The fusion layer can also intercept application requests for virtual processors and call upon multiple processors in the computing device to process these requests. This allows applications to directly call upon the virtual processor with a larger video memory capacity to perform computing tasks, without having to split the computing tasks. This method is applicable to computing tasks of any application in a computing device and offers high versatility.Furthermore, the fusion layer can invoke multiple processors in a computing device to process application call requests, thereby improving resource utilization of the multiple processors in the computing device. The technical solutions presented in this disclosure are described in detail below through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other, and identical or similar content will not be repeated in different embodiments. Figure 2 is a schematic flow diagram of a processor invocation method provided in an exemplary embodiment of this disclosure. Referring to Figure 2 , the method may include:
[0002] S201: Send virtual processor information of a virtual processor to a target application via a fusion layer. This embodiment is applied to a computing device equipped with multiple processors. Multiple processors can be two or more. For example, the computing device can be a server or a computer. The fusion layer can be a layer structure added to the system software layer of the computing device. The computing device involved in this embodiment is described below with reference to FIG3 . FIG3 is a schematic diagram of the structure of another computing device provided by an exemplary embodiment of the present disclosure. Referring to FIG3 , the computing device can include an application layer, a system software layer, and a hardware layer. The hardware layer can include processor 1, processor 2, ..., and processor n, where n is an integer greater than or equal to 2. Each processor can include video memory (not shown in FIG3 ). For example, the processor can be a GPU. The application layer can include application 1, application 2, ..., and application m, where m is an integer greater than or equal to 1. Applications in the application layer can call processors to perform computing tasks. For example, the application can be a GPU application. The target application can be any application in the application layer. The system software layer can include the fusion layer. The fusion layer can be used to collect processor information from multiple processors in a computing device. Processor information can include the number of processors and the processor's video memory capacity. The fusion layer can also be used to send virtual processor information to applications in the application layer. Virtual processor information includes the number of virtual processors and the virtual memory capacity corresponding to each virtual processor. The virtual memory capacity is the sum of the video memory capacities of multiple processors. A virtual processor can be a virtual device presented by the fusion layer to applications in the application layer. In this embodiment, multiple processors correspond to a virtual processor. That is, two or more processors correspond to one virtual processor. In one example, all processors in a computing device correspond to one virtual processor. In this example, the number of virtual processors can be one, and the virtual memory capacity corresponding to each virtual processor can be the sum of the video memory capacities of all processors in the computing device. In this example, the virtual memory capacity corresponding to the virtual processor is relatively large. This virtual processor can be used in scenarios with high video memory requirements, resulting in higher resource utilization for the virtual processor. In another example, multiple processors in a computing device correspond to one virtual processor, and the number of virtual processors is less than the number of processors in the computing device. In this example, the virtual memory capacity corresponding to the virtual processor may be the sum of the memory capacities of the multiple processors corresponding to the virtual processor. In this example, the number of processors is large, and the multiple processors can process computing tasks in parallel, resulting in higher processing efficiency of the computing tasks.
[0003] S202: Intercept the target application's call request for the virtual processor through the fusion layer. In this embodiment, the target application can issue a call request for the virtual processor by calling an application programming interface (API). The API can be provided in the system software layer. The API is described below with reference to FIG4 . FIG4 is a schematic diagram of the structure of a system software layer provided in an exemplary embodiment of the present disclosure. The system software layer shown in FIG4 can be the system software layer of the computing device provided in the embodiment of FIG3 . Referring to FIG4 , the system software layer can include a fusion layer and a user-mode driver layer. The user-mode driver layer can include multiple APIs. For example, the multiple APIs can include API1, API2, and API3. The multiple APIs included in the user-mode driver layer can be APIs provided by the processor manufacturer and exposed to the application layer. Specifically, the processor manufacturer can encapsulate different operations on the processor hardware into different APIs. The target application can perform different operations on the processor hardware by calling the APIs. For example, assuming that the processor manufacturer encapsulates the operation of requesting video memory space in the processor into API3, the target application can request video memory space in the processor by calling API3. The fusion layer can also include multiple APIs. For example, the multiple APIs may be API1, API2, and API3. The multiple APIs in the fusion layer may be identical to some of the APIs in the user-mode driver layer. Specifically, the user-mode driver layer may include two types of APIs. The first type of API may be an API related to the number of processors in the computing device and the usage of the processor's video memory; the second type of API may be an API unrelated to the number of processors in the computing device and the usage of the processor's video memory. In this embodiment, the multiple APIs included in the fusion layer may be APIs of the first type. That is, the user-mode driver layer may include both APIs of the first type and APIs of the second type, and the fusion layer may include APIs of the first type. In this embodiment, for any API of the first type, if the caller calls the API from the user-mode driver layer, it can be considered that the caller is requesting an operation on the processor; if the caller calls the API from the fusion layer, it can be considered that the caller is requesting an operation on the virtual processor. For example, the caller may be a target application. For example, assume that API3 can be used to request video memory space. If the target application calls API3 from the user-mode driver layer, it can be considered that the target application is requesting video memory space in the processor.If the target application calls API3 from the fusion layer, it can be considered that the target application is requesting virtual video memory space in the virtual processor. In this embodiment, the call priority of the API in the fusion layer is higher than the call priority of the API in the user-mode driver layer. Specifically, for any first-type API, if the target application calls that API, the computing device can prioritize the target application calling that API from the fusion layer, allowing the fusion layer to intercept the target application's call request. It should be noted that the API called by the target application to complete the computing task can be a first-type API. In other words, the target application can call the API from the fusion layer to complete the computing task. The target application can call the second-type API from the user-mode driver layer to avoid the high overhead of the fusion layer.
[0004] S203: Invoke multiple processors to process the call request. In this embodiment, the target application's call request for the virtual processor can be processed by the processor. Specifically, after the target application issues a call request for the virtual processor by calling an API in the fusion layer, the computing device can call the corresponding API in the user-mode driver layer through the fusion layer to enable the processor to process the call request. For example, assuming that API3 can be used to request video memory space, both the fusion layer and the user-mode driver layer include API3. After the target application calls API3, the computing device can intercept the target application's call request through the fusion layer and call API3 in the user-mode driver layer through the fusion layer to enable the processor to allocate video memory space for the target application. In this embodiment, the computing device can send virtual processor information of the virtual processor to the target application through the fusion layer, intercept the target application's call request for the virtual processor through the fusion layer, and invoke multiple processors to process the call request. Because the virtual memory capacity can be the sum of the memory capacities of multiple processors in a computing device, that is, the virtual memory capacity is relatively large, the target application can directly call the virtual processor to perform computing tasks without splitting the computing task. This avoids splitting the computing task based on specific computing scenarios and improves the versatility of computing. Furthermore, in the above method, the target application's call request for the virtual processor can be processed by multiple processors in the computing device, allowing the multiple processors in the computing device to be fully utilized and improving resource utilization of the multiple processors in the computing device. The following, based on the embodiment shown in FIG2 and in conjunction with FIG5, details a method for sending virtual processor information to a target application via the fusion layer, and a method for calling multiple processors to process the call request. FIG5 is a flow chart illustrating another processor calling method provided by an exemplary embodiment of the present disclosure. Referring to FIG5, the method may include:
[0005] S501. Intercept the target application's information acquisition request through the fusion layer. The information acquisition request is used to request processor information for multiple processors. The processor information may include the number of processors and the processor's video memory capacity. In this embodiment, the target application may request processor information by calling an API. For example, the target application may call an API for obtaining processor information to obtain the processor information. It should be noted that since the API for obtaining processor information is the first type of API described in S202, if the target application calls the API for obtaining processor information, the computing device may cause the target application to preferentially call the API from the fusion layer, so that the fusion layer can intercept the target application's information acquisition request.
[0006] S502. Determine virtual processor information based on the information acquisition request. The virtual processor information may include the number of virtual processors and the virtual memory capacity corresponding to the virtual processors. In this embodiment, processor information of multiple processors can be acquired in the computing device based on the information acquisition request. The processor information includes the memory capacity of the processor's video memory; the virtual memory capacity can be determined based on the processor information; and the virtual processor information can be determined based on the virtual memory capacity. Specifically, the fusion layer can call an API for acquiring processor information in the user-mode driver layer to acquire the number of multiple processors and the memory capacity of each processor. The fusion layer can determine the correspondence between multiple processors and virtual processors, and based on the correspondence, the number of multiple processors, and the memory capacity of each processor, the number of virtual processors and the virtual memory capacity can be determined. In this embodiment, it can be determined that one virtual processor corresponds to all processors in the computing device. In this case, the number of virtual processors can be one, and the virtual memory capacity can be the sum of the memory capacities of all processors in the computing device.
[0007] S503. Send virtual processor information to the target application. In this embodiment, the computing device may send the number of virtual processors and the virtual memory capacity corresponding to the virtual processors to the target application through the fusion layer, so that the target application knows the virtual memory capacity.
[0008] S504: Intercept the target application's call request to the virtual processor through the fusion layer. It should be noted that the specific implementation of S504 can be found in S202 and will not be repeated here.
[0009] S505. Determine the call type of the call request. In this embodiment, the API invoked by the call request can be determined; the call type is determined based on the API. Specifically, a preset correspondence exists between APIs and call types, which can include multiple APIs and the call type corresponding to each API. The computing device can determine the call type of the call request based on the API invoked by the call request and the preset correspondence. During implementation, the preset correspondence can be searched for the API invoked by the call request, and the call type corresponding to the API invoked by the call request in the preset correspondence can be determined as the call type of the call request. In this embodiment, the call type can include at least the following four cases: Case 1: The call type is an initialization type. In this case, the call request can be used to request the generation of a virtual runtime (context) for a virtual processor and obtain a virtual runtime handle of the virtual runtime, so that the target application can call the corresponding function based on the virtual runtime handle. Case 2: The call type is a video memory allocation type. In this case, the call request can be used to request virtual memory space for the virtual processor to facilitate the storage of target data in the virtual memory space. The target data can be data required to perform a computing task. In this case, the call request can include the target memory capacity requested for allocation. The target memory capacity can be the size of the requested virtual memory space. In case 3, the call type is an upload data type. In this case, the call request can be used to request the storage of target data in the virtual memory space to facilitate the virtual processor to perform a computing task based on the target data. In this case, the call request can include the target data to be uploaded. In case 4, the call type is an execution type. In this case, the call request can be used to call a function, causing the virtual processor to execute the corresponding function. In this case, the call request can include function parameters of the function to be called. Function parameters can include a virtual runtime handle and the virtual memory address to be used. The function to be called can be a computing function within the processor.
[0010] S506: Invoke multiple processors to process the call request based on the call type. In this embodiment, after the fusion layer intercepts the target application's call request to the virtual processor, it may invoke multiple processors to process the call request, thereby enabling multiple processors in the computing device to process the target application's call request. In this embodiment, different call types result in different methods for invoking multiple processors to process the call request. Depending on the call type, invoking multiple processors to process the call request may include at least the following four scenarios: Scenario 1: The call type is initialization. In this scenario, each processor may be initialized based on the initialization type to obtain a runtime handle corresponding to each processor; a virtual runtime handle may be generated based on the runtime handle corresponding to each processor; and the virtual runtime handle may be sent to the target application. The virtual runtime handle may be used by the target application to call the multiple processors. The virtual runtime handle may be the runtime handle of the virtual processor. In this embodiment, a mapping relationship exists between the virtual runtime handle and the runtime handle of each processor. Specifically, based on the call request, a runtime can be established for each processor corresponding to the virtual processor to obtain a runtime handle corresponding to each processor. A virtual runtime handle can then be generated based on the correspondence between the virtual processor and multiple processors and the runtime handle corresponding to each processor. The following describes the process of generating a virtual runtime handle, taking a computing device including two processors (GPU1 and GPU2) corresponding to a virtual processor as an example, with reference to FIG6 . FIG6 is a schematic diagram of a virtual runtime generation process provided by an exemplary embodiment of the present disclosure. Referring to FIG6 , it is assumed that the runtime handle generated for GPU1 is Runtime 1, and the runtime handle generated for GPU2 is Runtime 2. As shown in FIG6 , the fusion layer can obtain the runtime handles of GPU1 (i.e., Runtime 1) and GPU2 (i.e., Runtime 2), and can also generate a runtime handle for the virtual processor (i.e., the virtual runtime) based on the obtained runtime handles. In other words, there is a correspondence between the virtual runtime and Runtime 1 and Runtime 2. Case 2: The call type is video memory allocation. In this case, at least one storage space can be determined in multiple processors based on the target video memory capacity, with the sum of the sizes of the at least one storage space being equal to the target video memory capacity. A virtual address can be generated based on the physical address of the at least one storage space, and the virtual address can be sent to the target application. The at least one storage space can be a storage space in the video memory of at least one processor, or a free storage space in the video memory of the processor.Specifically, the computing device can determine at least one storage space based on the available space in the graphics memories of multiple processors through the fusion layer, and establish an address mapping relationship between the physical address and virtual address of the at least one storage space. The following describes the process of establishing the address mapping relationship, taking a computing device including two processors (GPU1 and GPU2) corresponding to virtual processors as an example, with reference to FIG7 . FIG7 is a schematic diagram of the process of establishing the address mapping relationship provided by an exemplary embodiment of the present disclosure. Referring to FIG7 , it is assumed that the at least one storage space is storage space 1 in GPU1 and storage space 2 in GPU2. As shown in FIG7 , the fusion layer can obtain the physical address of storage space 1 and the physical address of storage space 2, determine the physical address of storage space 1 and the physical address of storage space 2 corresponding to the virtual address, and send the virtual address to the target application. Case 3: The call type is an upload data type. In this case, the virtual address allocated to the target application is determined; at least one physical address corresponding to the virtual address is determined, where the at least one physical address is the address of at least one storage space in the multiple graphics memories of the multiple processors; and target data is stored in the at least one storage space based on the at least one physical address. Specifically, in this case, the call request may include the target data to be uploaded. The computing device may determine at least one physical address corresponding to the virtual address based on the virtual address and the address mapping relationship, and may store the target data in the video memory space corresponding to the at least one physical address. The following describes the process of storing target data, using an example in which the computing device includes two processors (GPU1 and GPU2) corresponding to virtual processors, with reference to Figure 8. Figure 8 is a schematic diagram of a target data storage process provided by an exemplary embodiment of the present disclosure. As shown in Figure 8, it is assumed that the at least one physical address corresponding to the virtual address is the physical address of storage space 1 and the physical address of storage space 2. As shown in Figure 8, the target application may send the target data to the fusion layer via a call request. The fusion layer may determine at least one physical address based on the virtual address and the address mapping relationship, and may store the target data in the video memory space corresponding to the at least one physical address. Case 4: The call type is execution. In this case, at least one first processor may be determined from among the multiple processors based on the function parameters, wherein the video memory of the first processor stores the to-be-processed data corresponding to the to-be-called function. Based on the runtime handle of the at least one first processor and the to-be-processed data, the at least one first processor may be called to execute the to-be-called function, thereby processing the call request.Function parameters may include a virtual runtime handle and the virtual video memory address used. The computing device may determine the video memory address of the processor corresponding to the virtual video memory address and the runtime handle of the processor corresponding to the virtual runtime handle through the fusion layer. The video memory address of the processor corresponding to the virtual video memory address may include an address in the video memory of at least one first processor. The runtime handle of the processor corresponding to the virtual runtime may include the runtime handle of at least one first processor. In this embodiment, if the number of at least one first processor is one, the computing device may call the first processor to execute the function to be called based on the runtime handle of the first processor and the data to be processed stored in the video memory of the first processor. If the number of at least one first processor is greater than one, a target processor and a migration processor may be determined within the at least one first processor; the data to be processed in the migration processor may be migrated to the target processor; and the target processor may be called based on the runtime handle of the target processor, so that the target processor processes the data to be processed using the function to be called and obtains a processing result. It should be noted that if the number of at least one first processor is greater than one, the target processor and the migration processor may be determined within the at least one first processor based on a preset migration policy. The preset migration policy can be set based on actual needs and is not limited in this embodiment. Below, taking a computing device including two processors (GPU1 and GPU2) corresponding to virtual processors as an example, with reference to FIG9 , the case where the number of at least one first processor is greater than one is described. FIG9 is a schematic diagram of a function execution process provided by an exemplary embodiment of the present disclosure. Referring to FIG9 , it is assumed that the at least one first processor is GPU1 and GPU2, the target processor is GPU2, the migration processor is GPU1, the data to be processed in GPU1 is stored in storage space 1, storage space 3 in GPU3 is free storage space, and the capacity of storage space 3 is greater than or equal to storage space 1. The data to be processed in storage space 1 can be migrated to storage space 3. Based on the runtime handle of GPU2 and the data to be processed stored in GPU2, the computing device can call GPU2 to execute the function to be called. It should be noted that after migrating the data to be processed in storage space 1 to storage space 3, the address mapping relationship between the physical address and the virtual address of at least one storage space can be updated to ensure the accuracy of the address mapping relationship. In this method, the video memories of multiple processors can be dynamically scheduled and used, resulting in higher processor resource utilization.Optionally, after migrating the pending data in storage space 1 to storage space 3, storage space 1 can be released so that it can be reused, improving storage space utilization. Optionally, in this case, the processing results can be retrieved from the target processor's video memory and sent to the target application. Specifically, after the target processor executes the function to be called, the processing results can be stored in the target processor's video memory. The computing device can retrieve the processing results from the target processor's video memory through the fusion layer and send the processing results to the target application. Optionally, after sending the processing results to the target application, the video memory allocated to the target application in multiple processors can be released, allowing other applications to use multiple processors, thereby improving processor resource utilization. In embodiments of the present disclosure, the computing device can intercept the target application's information acquisition request through the fusion layer, determine virtual processor information based on the information acquisition request, send the virtual processor information to the target application, intercept the target application's call request for the virtual processor through the fusion layer, determine the call type of the call request, and, based on the call type, call multiple processors to process the call request. Through the above method, the target application can be informed of the presence of a virtual processor with a large virtual video memory capacity in the computing device. The target application can then directly call the virtual processor to perform computing tasks without having to split the computing task, avoiding the need to split the computing task based on specific computing scenarios and improving computing versatility. Furthermore, in the above method, multiple processors in the computing device can process the target application's call request for the virtual processor, fully utilizing the processor resources in the computing device and improving processor utilization. Below, using a computing device including two processors (GPU1 and GPU2), which correspond to virtual processors, as an example, the processor call method provided by the present disclosure will be further described through a specific example in conjunction with Figure 10. Figure 10 is a flowchart illustrating another processor call method provided by an exemplary embodiment of the present disclosure. As shown in step ① of Figure 10, the computing device can determine virtual processor information based on GPU1 processor information and GPU2 processor information through the fusion layer and can send the processor information to the target application. After sending the processor information to the target application, the fusion layer can intercept the target application's initialization-type call request for the virtual processor.As shown in step ② of Figure 10 , the computing device can establish runtimes for GPU1 and GPU2 through the fusion layer. Based on the runtime handles of GPU1's runtime (i.e., Runtime 1) and GPU2's runtime (i.e., Runtime 2), a virtual processor runtime handle (i.e., virtual runtime) can be generated and sent to the target application. After sending the virtual runtime handle to the target application, the fusion layer can intercept the target application's memory allocation type call request for the virtual processor. As shown in step ③ of Figure 10 , based on the memory allocation type call request, at least one storage space can be determined to be storage space 1 in GPU1 and storage space 2 in GPU2. The virtual address can be determined to correspond to the physical address of storage space 1 and the physical address of storage space 2, and the virtual address can be sent to the target application. After sending the virtual address to the target application, the fusion layer can intercept the target application's upload data type call request for the virtual processor. As shown in Figure 10 (4), the target data can be stored in storage space 1 and storage space 2 via the fusion layer. After the target data is stored in storage space 1 and storage space 2, the fusion layer can intercept the target application's execution type call request for the virtual processor. As shown in Figure 10 (5), the data to be processed stored in GPU 1 can be migrated to GPU 2, and the function to be called can be executed by GPU 2. As shown in Figure 10 (6), after GPU 2 executes the function to be called, the processing result can be stored in GPU 2's video memory. The computing device can send the processing result to the target application via the fusion layer. Figure 11 is a schematic diagram of the structure of a processor calling device provided in an exemplary embodiment of the present disclosure. The processor calling device is applied to a computing device provided with multiple processors corresponding to virtual processors. Referring to FIG. 11 , the processor calling device 10 includes a sending module 11, an intercepting module 12, and a calling module 13. The sending module 11 is configured to send virtual processor information of the virtual processor to a target application via a fusion layer. The virtual processor information includes the number of virtual processors and the virtual memory capacity corresponding to the virtual processor, where the virtual memory capacity is the sum of the memory capacities of the multiple processors. The intercepting module 12 is configured to intercept a call request from the target application for the virtual processor via the fusion layer. The calling module 13 is configured to call the multiple processors to process the call request.The processor invocation device provided in the embodiments of the present disclosure can implement the technical solutions described in the above-mentioned method embodiments. The implementation principles and beneficial effects are similar and will not be further described here. In one possible implementation, the sending module 11 is specifically configured to intercept, via the fusion layer, an information acquisition request from the target application, the information acquisition request being for obtaining processor information of the multiple processors; determine the virtual processor information based on the information acquisition request; and send the virtual processor information to the target application. In one possible implementation, the sending module 11 is specifically configured to, based on the information acquisition request, obtain processor information of the multiple processors from the computing device, the processor information including the video memory capacity of the processors; determine the virtual video memory capacity based on the processor information; and determine the virtual processor information based on the virtual video memory capacity. In one possible implementation, the invocation module 13 is specifically configured to determine a call type of the call request, the call type including at least one of the following: initialization type, video memory allocation type, upload data type, or execution type; and, based on the call type, invoke the multiple processors to process the call request. In one possible implementation, the calling module 13 is specifically configured to determine the application programming interface (API) invoked by the call request; determine the call type based on the API. In one possible implementation, the call type is the initialization type; the calling module 13 is specifically configured to initialize each processor based on the initialization type to obtain a runtime handle corresponding to each processor; generate a virtual runtime handle based on the runtime handle corresponding to each processor; and send the virtual runtime handle to the target application, where the virtual runtime handle is used by the target application to call the multiple processors. In one possible implementation, the call type is the video memory allocation type, and the call request includes a target video memory capacity to be allocated; the calling module 13 is specifically configured to determine at least one storage space in the multiple processors based on the target video memory capacity, where the sum of the sizes of the at least one storage space is the target video memory capacity; generate a virtual address based on the physical address of the at least one storage space, and send the virtual address to the target application.In one possible implementation, the call type is the upload data type, and the call request includes the target data to be uploaded. The calling module 13 is specifically configured to determine a virtual address allocated for the target application; determine at least one physical address corresponding to the virtual address, where the at least one physical address is the address of at least one storage space in the multiple video memories of the multiple processors; and store the target data in the at least one storage space based on the at least one physical address. In another possible implementation, the call type is the execution type, and the call request includes function parameters of a function to be called. The calling module 13 is specifically configured to, based on the function parameters, determine at least one first processor among the multiple processors, wherein the video memory of the first processor stores the data to be processed corresponding to the function to be called; and, based on the runtime handle of the at least one first processor and the data to be processed, call the at least one first processor to execute the function to be called, thereby processing the call request. In one possible implementation, the number of the at least one first processor is greater than one; the calling module 13 is specifically configured to determine a target processor and a migration processor among the at least one first processor; migrate the pending data in the migration processor to the target processor; and call the target processor according to the runtime handle of the target processor, so that the target processor processes the pending data using the to-be-called function to obtain a processing result. In one possible implementation, the sending module 11 is further configured to retrieve the processing result from the graphics memory of the target processor and send the processing result to the target application. The processor calling device provided in this embodiment of the present disclosure can implement the technical solutions shown in the above-mentioned method embodiments. The implementation principles and beneficial effects are similar and will not be further described here. Figure 12 is a schematic structural diagram of another processor calling device provided in this exemplary embodiment of the present disclosure. Referring to Figure 12, based on the embodiment shown in Figure 11, the processor calling device 10 further includes a release module 14, wherein the release module 14 is configured to release the graphics memory allocated to the target application in the multiple processors. The processor-calling device provided in the embodiments of the present disclosure can implement the technical solutions described in the above-described method embodiments. The implementation principles and beneficial effects are similar and will not be further elaborated here. FIG13 is a schematic diagram of the structure of an electronic device provided in accordance with an exemplary embodiment of the present disclosure. Referring to FIG13 , the electronic device 20 may include a processor 21 and a memory 22. For example, the processor 21 and the memory 22 are interconnected via a bus 23.The memory 22 stores computer-executable instructions; the processor 21 executes the computer-executable instructions stored in the memory 22, causing the processor 21 to perform the method described in the above method embodiments. The electronic device shown in FIG13 may be the computing device described in any of the above embodiments. Accordingly, embodiments of the present disclosure provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by the processor, they are used to implement the method described in the above method embodiments. Accordingly, embodiments of the present disclosure may also provide a computer program product, including a computer program. When executed by the processor, the computer program may implement the method described in the above method embodiments. Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process flow and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-volatile memory in the form of random access memory (RAM) and / or non-volatile memory such as read-only memory (ROM) or flash memory. Memory is an example of a computer-readable medium. Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can implement information storage using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves. It should also be noted that the terms "comprises," "comprising," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements may include not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus. In the absence of further limitations, elements defined by the phrase "comprising a..." do not preclude the presence of other identical elements in the process, method, product, or device comprising the elements. The foregoing description is merely an embodiment of the present disclosure and is not intended to limit the present disclosure. Persons skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.
Claims
Claims 1. A method for calling a processor, wherein: Applied to a computing device, the computing device being provided with multiple processors, the multiple processors corresponding to virtual processors, the method comprising: sending virtual processor information of the virtual processors to a target application via a fusion layer, the virtual processor information including the number of the virtual processors and the virtual video memory capacity corresponding to the virtual processors, the virtual video memory capacity being the sum of the video memory capacities of the multiple processors; intercepting, via the fusion layer, a call request from the target application to the virtual processor, and calling the multiple processors to process the call request.
2. The method according to claim 1, wherein: Sending virtual processor information of the virtual processor to a target application through a fusion layer includes: intercepting, through the fusion layer, an information acquisition request of the target application, the information acquisition request being used to request acquisition of processor information of the multiple processors; determining the virtual processor information based on the information acquisition request, and sending the virtual processor information to the target application.
3. The method according to claim 2, wherein: Determining the virtual processor information according to the information acquisition request includes: obtaining processor information of the multiple processors in the computing device according to the information acquisition request, the processor information including video memory capacity of video memory in the processor; determining the virtual video memory capacity according to the processor information; and determining the virtual processor information according to the virtual video memory capacity.
4. The method according to any one of claims 1 to 3, wherein: Calling the multiple processors to process the call request includes: determining a call type of the call request, where the call type includes at least one of the following: an initialization type, a video memory allocation type, an upload data type, or an execution type; and calling the multiple processors to process the call request according to the call type.
5. The method according to claim 4, wherein: Determining the call type of the call request includes: determining an application programming interface API called by the call request; and determining the call type according to the API.
6. The method according to claim 4 or 5, wherein: The calling type is the initialization type; Calling the multiple processors to process the call request according to the call type includes: initializing each processor according to the initialization type to obtain a runtime handle corresponding to each processor; generating a virtual runtime handle according to the runtime handle corresponding to each processor; and sending the virtual runtime handle to the target application, where the virtual runtime handle is used by the target application to call the multiple processors.
7. The method according to claim 4 or 5, wherein: The calling type is the video memory allocation type, and the calling request includes a target video memory capacity requested for allocation; Invoking the multiple processors to process the call request according to the call type includes: determining at least one storage space in the multiple processors according to the target video memory capacity, where the sum of sizes of the at least one storage space is the target video memory capacity; Generate a virtual address according to the physical address of the at least one storage space, and send the virtual address to the target application.
8. The method according to claim 4 or 5, wherein: The call type is the upload data type, and the call request includes the target data to be uploaded; Invoking the plurality of processors to process the call request according to the call type, comprising: determining a virtual address allocated to the target application; Determine at least one physical address corresponding to the virtual address, where the at least one physical address is an address of at least one storage space in a plurality of display memories of the plurality of processors; and store the target data in the at least one storage space according to the at least one physical address.
9. The method according to claim 4 or 5, wherein: The calling type is the execution type, and the calling request includes function parameters of the function to be called; Calling the multiple processors to process the call request according to the call type includes: determining at least one first processor among the multiple processors according to the function parameters, wherein a video memory of the first processor stores to-be-processed data corresponding to the to-be-called function; According to the runtime handle of the at least one first processor and the data to be processed, the at least one first processor is called to execute the function to be called, so as to process the calling request.
10. The method according to claim 9, wherein: The number of the at least one first processor is greater than one; based on the runtime handle of the at least one first processor and the data to be processed, the at least one first processor is called to execute the function to be called to process the call request, including: determining a target processor and a migration processor in the at least one first processor; migrating the data to be processed in the migration processor to the target processor; and calling the target processor based on the runtime handle of the target processor, so that the target processor processes the data to be processed through the function to be called to obtain a processing result.
11. The method according to claim 10, wherein: The method further includes: acquiring the processing result in a video memory of the target processor, and sending the processing result to the target application.
12. The method according to claim 11, wherein: The method further includes: releasing video memory in the plurality of processors allocated for the target application.
13. A processor calling device, wherein: Applied to a computing device, the computing device is provided with multiple processors, the multiple processors correspond to virtual processors, the apparatus comprises: a sending module, an intercepting module and a calling module, wherein: The sending module is configured to send virtual processor information of the virtual processor to a target application through a fusion layer, where the virtual processor information includes the number of virtual processors and the virtual memory capacity corresponding to the virtual processor, where the virtual memory capacity is the sum of the memory capacities of the multiple processors. The intercepting module is configured to intercept a call request from the target application for the virtual processor through the fusion layer. The calling module is configured to call the multiple processors to process the call request.
14. An electronic device, wherein: include: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the electronic device to perform the method according to any one of claims 1 to 12.
15. A computer-readable storage medium, wherein: The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the method according to any one of claims 1 to 12 is implemented.
16. A computer program product, comprising a computer program, wherein: When the computer program is executed by a processor, the method according to any one of claims 1 to 12 is implemented.
Citation Information
Patent Citations
Resource management method and device, electronic equipment and storage medium
CN112825042A
Method and device for allocating GPU physical memories
CN113377545A
Video memory allocation method and device, electronic equipment and readable storage medium
CN113835887A
Dynamic allocation of physical graphics processing units to virtual machines
WO2014100558A1