Communication method, device and system, computer program product and storage medium

Abstract

The embodiment of the invention provides a communication method, device and system, a computer program product and a storage medium. When monitoring that the application program calls any application programming interface in any interface library, the first computing end intercepts calling of the application program to the application programming interface; and constructing protocol data required by execution for the application programming interface, and forwarding the protocol data to a second computing end to trigger the second computing end to call to the application programming interface from an interface library provided by the second computing end, and executing a processing task indicated by the application program by using an image processing unit assembled on the second computing end. Accordingly, interface unification can be achieved between the first computing end and the second computing end through the protocol data, various interface libraries can be effectively compatible in the first computing end, cross-end GPU calling of the first computing end can be supported by constructing and forwarding the protocol data, and therefore the response efficiency of the application program is improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a communication method, device, system, computer program product, and storage medium. Background Technology

[0002] A Graphics Processing Unit (GPU) is a specialized processor designed for efficient graphics rendering and parallel computing tasks. With its superior parallel computing capabilities, GPUs have become a key player in cloud computing for handling large-scale data and high-load computing tasks.

[0003] Currently, due to the characteristics of cloud computing, the resource allocation between CPUs and GPUs on cloud servers is usually fixed. However, the GPU resource usage requirements of applications running on cloud servers are complex and variable. Thus, if a cloud server lacks a GPU or has insufficient GPU resources, the GPU usage requirements of applications may not be met, thereby affecting application response latency. Summary of the Invention

[0004] This application provides a communication method, device, system, computer program product, and storage medium to improve the responsiveness of applications when applications require the use of GPUs.

[0005] This application provides a communication method applicable to a first computing terminal, the method comprising:

[0006] In response to detecting that an application calls any application programming interface in any interface library, the application calls to the application programming interface are intercepted, and the application programming interface is used to control the graphics processing unit to perform processing tasks;

[0007] Build the protocol data required for execution for the application programming interface;

[0008] The protocol data is forwarded to the second computing terminal to trigger the second computing terminal to call the application programming interface from its own interface library according to the protocol data, so as to use the image processing unit assembled on the second computing terminal to complete the processing task.

[0009] This application embodiment also provides a communication method applicable to a second computing terminal, the method comprising:

[0010] After receiving the protocol data sent by the first computing terminal, the application programming interface corresponding to the protocol data is parsed. The protocol data is constructed by the first computing terminal after detecting that the application calls the application programming interface.

[0011] The application programming interface is called from the interface library provided by the second computing terminal itself;

[0012] Based on the protocol data, the interface logic corresponding to the application programming interface is executed to control the second computing terminal to execute the processing task indicated by the application when it calls the application programming interface.

[0013] This application also provides a communication system, including a first computing terminal and a second computing terminal;

[0014] The first computing terminal is configured to, in response to detecting that an application calls any application programming interface (API) in any interface library, intercept the application's call to the API, wherein the API is used to control the graphics processing unit to perform processing tasks; construct the protocol data required for the execution of the API; and forward the protocol data to the second computing terminal.

[0015] The second computing terminal is configured to parse the application programming interface (API) corresponding to the protocol data; call the API from its own provided interface library; and execute the interface logic corresponding to the API based on the protocol data, so as to use the second computing terminal to perform the processing task.

[0016] This application also provides a computing device, including a memory, a processor, and a communication component;

[0017] The memory is used to store one or more computer instructions;

[0018] The processor is coupled to the memory and the communication component to execute one or more computer instructions for performing the aforementioned communication method executed by the first or second computing terminal.

[0019] This application also provides a computer-readable storage medium for storing a computer program, which, when executed by one or more processors, causes the one or more processors to execute the aforementioned communication method executed by a first computing terminal or a second computing terminal.

[0020] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to execute the aforementioned communication method executed by a first computing terminal or a second computing terminal.

[0021] This application proposes a cross-platform GPU invocation mechanism. A call interception mechanism for application programming interfaces (APIs) is set up in the first computing terminal. Based on this, when the first computing terminal detects an application calling any API from any API library, it will intercept the application's call to the API. Furthermore, the first computing terminal can construct the necessary protocol data for the execution of the API and forward this protocol data to the second computing terminal. This triggers the second computing terminal to call the API from its own provided interface library, thereby utilizing the image processing unit mounted on the second computing terminal to execute the processing task indicated by the application. Accordingly, the first computing terminal no longer directly forwards the application's calls to APIs, but instead constructs protocol data for APIs in various interface libraries. This protocol data unifies the implementation interface between the first and second computing terminals, enabling the first computing terminal to effectively support various interface libraries and achieve cross-platform GPU invocation by constructing and forwarding protocol data. In this way, cross-platform GPU invocation can be achieved without modification or awareness of the application, thereby improving the application's response efficiency. Attached Figure Description

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

[0023] Figure 1 A schematic diagram of the structure of a communication system provided for an exemplary embodiment of this application;

[0024] Figure 2a A logical schematic diagram illustrating a preferred implementation of an exemplary embodiment of this application;

[0025] Figure 2b A schematic diagram of the structure of another communication system provided in an exemplary embodiment of this application;

[0026] Figure 3 A flowchart illustrating a communication method provided for another exemplary embodiment of this application;

[0027] Figure 4 A flowchart illustrating another communication method provided for another exemplary embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of a computing device provided as another exemplary embodiment of this application. Detailed Implementation

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

[0030] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this application, the following is a brief explanation of several technical concepts involved in this application.

[0031] A Graphics Processing Unit (GPU) is a specialized processor designed for efficient graphics rendering and parallel computing tasks. With its superior parallel computing capabilities, the GPU plays a crucial role in cloud computing for handling large-scale data and high-load computing tasks. Hereinafter, the Graphics Processing Unit will be referred to as a GPU.

[0032] An interface library refers to a collection of application programming interfaces (APIs) that can be called by applications. In the embodiments of this application, it specifically refers to various interface libraries used to control the GPU, including but not limited to graphics rendering libraries such as the Open Graphics Library (Open GL) and the Open Graphics Library for Embedded Systems (Open GLES), and parallel computing libraries such as the Compute Unified Device Architecture (CUDA) library. Based on the APIs provided by these interface libraries, applications can control the GPU to perform image rendering tasks or parallel computing tasks.

[0033] An Application Programming Interface (API) is a set of encapsulated code that allows developers to achieve certain purposes without understanding the internal workings of the interface. In the embodiments of this application, the API specifically refers to the API used to control the GPU to perform processing tasks. Hereinafter, the API will be referred to as an API.

[0034] As described in the background section, some cloud servers may not be equipped with GPUs. In this case, if an application on the cloud server wants to use the GPU to perform some processing tasks, these tasks usually need to be executed by the cloud server's CPU. However, the CPU's processing power and efficiency are insufficient, resulting in poor application response efficiency. Even if some cloud servers are equipped with GPUs, GPU resources are insufficient. In this case, if an application on the cloud server wants to use the GPU to perform some processing tasks, it usually needs to queue and wait, resulting in poor application response efficiency. Therefore, this application proposes a communication scheme to improve application response efficiency in these situations.

[0035] The communication scheme proposed in this application designs a cross-platform GPU invocation mechanism that supports CPU and GPU decoupling. This GPU invocation mechanism involves two computing ends: the invoking end and the invoking end. This decoupling can be understood as follows: the CPU of the invoking end can borrow the GPU mounted on the invoking end via the network to complete the processing tasks indicated by the application on the invoking end.

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

[0037] Figure 1 This is a schematic diagram of the structure of a communication system provided for an exemplary embodiment of this application. For example... Figure 1 As shown, the system may include: a first computing terminal and a second computing terminal. It should be understood that the number of both the calling terminal and the called terminal in this communication system can be multiple. To better illustrate the cross-terminal GPU calling mechanism in this embodiment, in Figure 1 Only one calling end (i.e., the first computing end) and one called end (i.e., the second computing end) are shown. The first computing end can be a cloud server, or it can be a user terminal, etc. Furthermore, this embodiment does not limit whether the first computing end is equipped with a GPU. In this embodiment, the second computing end typically uses a cloud server to ensure processing efficiency, and the second computing end needs to be equipped with a GPU. The cloud server in this embodiment can refer to a physical server in the cloud or a virtual machine (VM), etc., and is not limited here.

[0038] The following is combined first Figure 1 The technical solution for the first computing terminal side is explained.

[0039] refer to Figure 1 In this embodiment, the first computing terminal can intercept the application's call to any API in any interface library in response to detecting that the application is calling any API.

[0040] In this embodiment, the type of interface library supported on the first computing terminal is not limited, and may include, but is not limited to, the OpenGL library and Open GLES library mentioned above. No further examples will be given here.

[0041] The interface library contains APIs that can be used to control the GPU to perform processing tasks. Based on this, in the first computing terminal, the application can indicate the processing task to be performed by calling the APIs in the interface library.

[0042] In this embodiment, an API call interception mechanism is designed on the first computing end side. The first computing end can intercept API calls from applications according to this mechanism. In other words, when the first computing end detects that an application has initiated a call request for any API in any interface library, it will not execute the interface logic of that API, but will intercept the API call request and automatically trigger the execution of the next processing step designed in this embodiment.

[0043] refer to Figure 1 In this embodiment, the next processing step designed on the first computing terminal side is as follows:

[0044] Build the protocol data required for execution for the application programming interface.

[0045] As mentioned earlier, cross-platform GPU invocation mechanisms involve two computing ends: the calling end and the called end. The calling end and the called end need to interact over the network to achieve cross-platform GPU invocation. Therefore, this embodiment designs a forwarding protocol to support cross-platform GPU invocation mechanisms. The calling end and the called end can follow this forwarding protocol to encapsulate the data that needs to be transmitted over the network, ensuring that the other party can understand and use the relevant data without difficulty.

[0046] In this embodiment, functional logic for constructing protocol data is written on the first computing end side. Based on this functional logic, the first computing end can construct the protocol data required for the execution of the API called by the application. That is, the protocol data in this embodiment may contain relevant data required for API execution. The protocol data in this embodiment conforms to the protocol format required by the aforementioned forwarding protocol. Under some exemplary protocol formats, the protocol data in this embodiment may include, but is not limited to, the API interface identifier and interface parameters. This is only an example, and the protocol format will not be described in detail here. In actual applications, it can be designed as needed to ensure that the calling end (i.e., the first computing end in this embodiment) and the called end (i.e., the second computing end in this embodiment) follow a consistent protocol format.

[0047] refer to Figure 1The first computing end can forward the protocol data constructed for the API to the second computing end. Based on the cross-end GPU call mechanism in this embodiment, the API needs to be executed by the second computing end. To this end, the first computing end can transmit the relevant data required by the API to the second computing end through protocol data. As mentioned above, in accordance with the forwarding protocol, the second computing end can understand the protocol data without difficulty, and the protocol data can trigger the second computing end to perform subsequent operations.

[0048] The following is combined Figure 1 The technical solution for the second computing terminal is explained.

[0049] refer to Figure 1 After receiving the protocol data sent by the first computing terminal, the second computing terminal can parse the API corresponding to the protocol data, thereby knowing which API the application in the first computing terminal expects to call.

[0050] Optionally, in this embodiment, a proxy process can be started on the second computing terminal on an application-by-application basis. The proxy process interacts with the calling terminal where the application resides to realize the cross-terminal GPU calling mechanism in this embodiment. The proxy process will not be described further hereafter, but it should be understood that the relevant technical solutions in this embodiment can be executed by the proxy process on the second computing terminal.

[0051] In this embodiment, the second computing terminal itself can provide multiple interface libraries to cover the interface libraries that different calling terminals may use. Therefore, the interface libraries provided by the second computing terminal itself include the APIs called by the application on the first computing terminal. Based on this, refer to Figure 1 The second computing terminal can call the API corresponding to the protocol data from its own interface library, which is the API called by the application on the first computing terminal.

[0052] As mentioned earlier, the protocol data contains the relevant data required for the API execution. Based on this, in this embodiment, the second computing terminal can execute the interface logic corresponding to the API based on the protocol data to control the GPU mounted on the second computing terminal to execute the processing task indicated by the application when calling the API. It should be understood that in the first computing terminal, the application can indicate the processing task by calling the API. The processing task can be understood as consisting of the interface parameters and other data set by the application and the interface logic of the API. Therefore, by executing the interface logic of the API according to the interface parameters and other data set by the application, the corresponding processing task can be completed. In this embodiment, the second computing terminal can parse the relevant data required for API execution, such as interface parameters, from the protocol data. Then, it can execute the interface logic of the API based on this data to complete the processing task indicated by the application.

[0053] It is worth emphasizing that in this embodiment, the operating system in the first computing terminal does not execute the API called by the application. Therefore, the first computing terminal will not generate operation instructions corresponding to the API (for example, when executing an API in the OpenGL library, a series of rendering instructions are generated). It is understood that the protocol data in this embodiment will not contain operation instructions corresponding to the API. In this embodiment, what is transmitted to the second computing terminal through the protocol data is not the operation instructions corresponding to the API, but rather the API interface identifier and the interface parameters configured by the application, so that the second computing terminal can know which API the application expects to call and which interface parameters are configured when calling the API. In this embodiment, the second computing terminal (specifically, the proxy thread started by the application mentioned above) acts as the caller, independently initiating the call to the corresponding API in the second computing terminal. Operation instructions are generated only after the API is called in the second computing terminal, and these operation instructions drive the GPU mounted on the second computing terminal.

[0054] In summary, this embodiment proposes a cross-platform GPU invocation mechanism. A call interception mechanism for application programming interfaces (APIs) is set up in the first computing terminal. Based on this, when the first computing terminal detects an application calling any API from any API library, it will intercept the application's call to the API. Furthermore, the first computing terminal can construct the necessary protocol data for the execution of the API and forward this protocol data to the second computing terminal. This triggers the second computing terminal to call the API from its own provided interface library, thereby utilizing the image processing unit mounted on the second computing terminal to execute the processing task indicated by the application. Accordingly, the first computing terminal no longer directly forwards the application's calls to APIs; instead, it constructs protocol data for APIs in various interface libraries. This protocol data unifies the implementation interface between the first and second computing terminals, enabling the first computing terminal to effectively support various interface libraries and achieve cross-platform GPU invocation by constructing and forwarding protocol data. Thus, cross-platform GPU invocation can be achieved without modification or awareness of the application, thereby improving the application's response efficiency.

[0055] In the above or following embodiments, various implementation methods can be used to construct the protocol data required for the execution of the called API on the first computing terminal side. A preferred implementation method is provided below. Figure 2a A logical diagram illustrating a preferred implementation of an exemplary embodiment of this application.

[0056] Referring to Figure 2, this preferred implementation proposes: designing a target dynamic library and providing multiple custom functions within it. These custom functions support cross-platform GPU calling mechanisms. Based on this, each calling end in the communication system can use the target dynamic library provided in this embodiment; that is, the target dynamic library provided in this embodiment can be reused by multiple calling ends. Here, a dynamic library is a form of software component that can be loaded into the application at runtime to implement specific functions, without needing to statically link the library code into the application at compile time. Therefore, introducing a dynamic library does not require modifying the application's program code.

[0057] During their research, the inventors discovered that applications on different calling ends use diverse interface libraries, such as the OpenGL library and OpenGLES library mentioned earlier. In response, this embodiment provides custom functions in the target dynamic library that are compatible with the API functionalities of various interface libraries. Therefore, the target dynamic library is compatible with various interface libraries. Furthermore, the target dynamic library in this embodiment supports flexible updates as needed. For example, it supports adding or deleting custom functions as needed, and it also supports modifying the function logic of custom functions in the target dynamic library. Further examples are not provided here.

[0058] In addition to the target dynamic library, this embodiment also includes a driver program designed for the scheduling end to support cross-platform GPU scheduling mechanisms. The scheduling end can install this driver program. This driver program allows for some initialization configurations on the scheduling end. Optionally, the driver program can be configured with a list of applications that need to call the GPU across platforms. Based on this, after any application on the first computing end starts, the first computing end can use the driver program to detect whether the application is on the aforementioned application list. If so, the target dynamic library provided in this embodiment is loaded into the application to process the API calls initiated by the application according to the technical solution provided in this embodiment. It is worth noting that the driver program here may only participate in the initialization configuration phase and does not need to participate in the API call processing process. Of course, this embodiment does not limit this.

[0059] Based on this, in this preferred implementation: after the first computing terminal intercepts the application's call to the API, it can automatically call the target function in the target dynamic library that is functionally adapted to the API. Here, functional adaptation can be understood as adapting to the API's interface functionality. It should be understood that different APIs may correspond to different interface functionalities, and the interface parameters required to implement these functionalities may also differ. Based on these differences, in this embodiment, the target dynamic library can design custom functions for APIs with different interface functionalities.

[0060] This preferred implementation further proposes that APIs with consistent functionality but inconsistent labeling in different interface libraries can be adapted to the same function in the target dynamic library. In this way, for APIs with consistent functionality, the same handling scheme can be adopted (i.e., executing the same function in the target dynamic library) to achieve a cross-platform GPU calling mechanism. For example, the OpenGLES library is a subset of the OpenGL library, focusing more on providing 3D graphics-related APIs for handheld and embedded devices. There are some APIs with consistent functionality but inconsistent labeling in the OpenGLES and OpenGL libraries; these APIs can reuse the same function in the target dynamic library.

[0061] Therefore, this design concept of function reuse can effectively reduce the number of functions in the target dynamic library, thereby saving development complexity and improving function maintainability.

[0062] It should be understood that the above-mentioned function reuse design concept is only a preferred option, and this embodiment is not limited to it. For example, custom functions that adapt to the functions of each API in various interface libraries can also be designed one-to-one in the target dynamic library. This design concept may result in a larger number of functions in the target dynamic library, but it does not affect the implementation of the cross-end GPU calling mechanism in this embodiment.

[0063] refer to Figure 2a As can be seen, in this preferred implementation, after the application on the first computing terminal calls any API in any interface library, it does not execute the interface logic of that API. Instead, it automatically calls the target function in the target dynamic library that is compatible with the API's functionality. In other words, the first computing terminal can intercept the application's API based on the target dynamic library. When it detects that the application has initiated a call request for any API in any interface library, it can intercept the call request and automatically call the target function in the target dynamic library.

[0064] Based on the target dynamic library, various implementation methods can be used to support the API interception process.

[0065] In a preferred implementation: the first computing terminal can bridge the custom functions in the target dynamic library to the APIs in the interface library used by the application, based on the functional compatibility between the APIs in the interface library used by the application and the custom functions in the target dynamic library. In this embodiment, bridging can be understood as establishing a connection between the function logic of the custom function and the call entry point of the corresponding API in the interface library. Thus, when an API is called, it can automatically switch to calling the custom function in the target dynamic library that is functionally compatible with that API.

[0066] Based on this preferred implementation, in the first computing terminal, API calls initiated by the application can be intercepted through bridging without the application's awareness, and automatically switched to calling the corresponding custom function in the target dynamic library. This can be achieved solely by relying on the target dynamic library without requiring development or modification of other software components, thus resulting in low development costs. Of course, this is only one preferred implementation. Other implementation methods can also be used to support this API interception stage in this embodiment. For example, the aforementioned driver can be designed with listening logic for API call entry points and calling logic for custom functions in the target dynamic library. In this way, the driver can participate in the API call processing process, assisting in the execution of the API interception stage. This embodiment is not limited to this, and further examples of implementation methods will not be provided here.

[0067] Based on this, continue to refer to Figure 2a The first computing end can construct the protocol data required for execution of the API called by the application according to the function logic of the target function. In this preferred implementation, function logic for constructing protocol data is written in each custom function of the target dynamic library. Based on this function logic, the first computing end executes the target function, thus constructing the protocol data required for execution of the API called by the application. The protocol data in this embodiment conforms to the protocol format required by the aforementioned forwarding protocol. The protocol format will not be elaborated here; in practical applications, it can be designed as needed, ensuring that the calling end and the called end adhere to a consistent protocol format.

[0068] As mentioned earlier, the protocol data in this embodiment may include, but is not limited to, the API's interface identifier and interface parameters. In response, the first computing end can obtain the interface parameters set by the application when calling the API according to the function logic of the target function; and, based on the API's interface identifier and the obtained interface parameters, construct the protocol data required for the API's execution according to a preset forwarding protocol. The constructed protocol data conforms to the protocol format required by the forwarding protocol.

[0069] In this preferred implementation, it is also proposed that after completing the processing task, the second computing terminal can send the processing result to the first computing terminal via the network, and the first computing terminal can then return the processing result to the application. Optionally, function logic for returning the processing result can be written in each custom function in the target dynamic library. Based on this, the processing result can be used as the return value corresponding to the protocol data to trigger the aforementioned target function in the first computing terminal to return the processing result to the application according to this part of the function logic. Of course, this is only optional, and the method of returning the processing result is not limited in this embodiment, and no further examples are given here.

[0070] It should be understood that using a self-designed target dynamic library to construct protocol data for the called API on the first computing end is only one optional implementation method. In this embodiment, the first computing end can also use other implementation methods to construct protocol data for the called API. For example, a kernel-mode functional module can be added to the kernel mode of the first computing end. The working logic of this kernel-mode functional module can be designed according to the protocol format of the protocol data required in this embodiment, so as to construct protocol data for the called API through this kernel-mode functional module. Other implementation methods will not be elaborated here.

[0071] In summary, this embodiment incorporates a self-designed target dynamic library in the first computing terminal. The custom functions provided in this target dynamic library serve as a unified abstract interface, compatible with various interface libraries that the application may use. Based on this, when the first computing terminal detects an application calling any application programming interface (API) from any interface library, it automatically executes the target function in the target dynamic library that is functionally compatible with that API. The target function can construct the necessary protocol data for the API's execution according to a preset forwarding protocol. The first computing terminal can forward this protocol data to the second computing terminal, triggering the second computing terminal to call the API from its own provided interface library. The second computing terminal then utilizes the image processing unit mounted on it to execute the processing task indicated by the application. Therefore, the target dynamic library effectively supports various interface libraries, enabling cross-platform GPU calls initiated by the application on the first computing terminal to be forwarded to the second computing terminal without modification or awareness of the application, thereby improving the application's response efficiency.

[0072] The above or following embodiments also propose a design concept that supports interface logic reuse in the called end. Based on this design concept, in this embodiment, on the second computing end side, APIs with consistent functions but inconsistent identifiers located in different interface libraries can reuse the same interface logic.

[0073] To support the design concept of interface logic reuse, a preferred implementation proposes that: the second computing end can establish an interface index table for the interface library required by the application. This index table contains interface pointers created for each API in the interface library, and these pointers point to the interface logic. Based on this, after receiving protocol data, the first computing end can search the interface index table corresponding to the application for the interface logic pointed to by the interface pointer of the API called by the application. Then, based on the protocol data, it executes the found interface logic. Here, the interface pointer is a pointer variable that points to the interface logic; it can point to the access address of a specific interface logic, allowing the operating system to access and execute that interface logic through this pointer variable.

[0074] In this preferred implementation, the second computing terminal can maintain separate interface index tables for different applications, and the interface pointers in the interface index tables are used to point to the interface logic. In this way, the interface pointers corresponding to APIs with the same function but different names may be distributed in different interface index tables, but these interface pointers can point to the same interface logic.

[0075] For example, suppose application A uses the OpenGL library and application B uses the OpenGLES library. The second computing end can maintain interface index table 1 for application A and interface index table 2 for application B. API1 in the OpenGL library and API2 in the OpenGLES library have the same function but different names. Then, the interface pointer corresponding to API1 in interface index table 1 and the interface pointer corresponding to API2 in interface index table 1 point to the same interface logic.

[0076] In this embodiment, the first computing terminal can pre-notify the second computing terminal of the interface libraries required by the application. Optionally, in this embodiment, a code segment for initialization configuration can be written in the target dynamic library. After the application loads the target dynamic library, the first computing terminal can use this code segment to determine the interface library to which the API called by the application belongs. Based on the type identifier corresponding to the determined interface library, the first computing terminal can construct a notification message conforming to the aforementioned forwarding protocol and send it to the second computing terminal. After receiving this notification message, the second computing terminal can determine the interface library required by the application on the first computing terminal.

[0077] In this embodiment, by reusing interface logic, only one set of interface logic needs to be designed for multiple APIs with consistent functionality, which effectively reduces code redundancy. It should be understood that this is only a preferred embodiment, and this embodiment is not limited thereto; further examples will not be provided here.

[0078] In the above or following embodiments, it is also proposed that the called end used by the first computing end can be fixed or dynamically allocated.

[0079] Figure 2b This is a schematic diagram of another communication system provided as an exemplary embodiment of this application. (Reference) Figure 2b The second computing endpoint can be located within the GPU resource pool. (See reference) Figure 2bThe GPU resource pool may contain multiple computing terminals equipped with GPUs, and may also include a scheduler. Based on this, the aforementioned first computing terminal can send protocol data to the scheduler, which then determines, according to a resource scheduling policy, which computing terminal in the GPU resource pool needs to forward the protocol data to. This determined computing terminal serves as the second computing terminal in this embodiment. The scheduler can then forward the protocol data sent by the first computing terminal to the second computing terminal.

[0080] In this embodiment, GPU resource pooling can dynamically allocate callees to each calling end, thereby achieving dynamic scheduling of GPU resources and improving the utilization rate of GPU resources.

[0081] In the above or following embodiments, it is also proposed that different solutions can be adopted for different types of operating systems to bridge the custom functions in the target dynamic library to the API in the interface library used by the application.

[0082] As mentioned earlier, the target dynamic library contains code segments for initialization configuration. In this embodiment, the target dynamic library can be bridged to the interface library used by the application through these code segments in the first computing terminal.

[0083] For desktop operating systems

[0084] If the first computing terminal uses a desktop operating system, the custom functions contained in the target dynamic library can be registered as hook functions. For each API contained in one or more interface libraries loaded by the application, a matching hook function is found to establish an association between the API and the hook function for the application. This association can be understood as a listening relationship; the specific event that the hook function is interested in is the invocation of its associated API.

[0085] In this context, a desktop operating system can be understood as an operating system running on devices such as servers. Typical desktop operating systems include Windows and Linux. In a desktop operating system, applications typically load one or more interface libraries, such as the aforementioned OpenGL library. The APIs contained in these libraries already possess the interface logic to implement the interface functions. However, in this embodiment, when the first computing terminal detects that an application calls any API in any interface library, it does not execute the API's existing interface logic. Instead, following the hook function mechanism, based on the aforementioned association, it automatically calls back the target function related to that API.

[0086] Thus, in this embodiment, for the desktop operating system, a hook function mechanism can be used to bridge the custom functions in the target dynamic library to the APIs in the interface library used by the application. The desktop operating system on the first computing end can automatically call back the hook function (i.e., the target function in the target dynamic library) associated with any API (i.e., a specific event) when it detects that the application calls any API in any interface library. It should be understood that the desktop operating system natively supports the hook function mechanism. In this embodiment, after the custom function in the target dynamic library is registered as a hook function, the desktop operating system can perform event listening and automatic callback according to the hook function mechanism, without involving any modification to the program code.

[0087] For mobile operating systems

[0088] If the first computing terminal uses a mobile operating system, it provides the application with entry points for calling APIs from one or more interface libraries. The entry point for any API provided to the application is then set to point to a custom function in the target dynamic library that is compatible with the API's functionality. Here, the mobile operating system can be understood as the operating system running on a mobile device; typical mobile operating systems include Android.

[0089] In this embodiment, for the mobile operating system, the custom functions in the target dynamic library are simulated as APIs in one or more interface libraries that can be called by the application. Thus, from the application's perspective, it perceives itself as calling APIs used to control the GPU, but these APIs are actually the custom functions in the target dynamic library in this embodiment. Based on this, the first computing terminal can automatically call the custom function adapted to the functionality of the application programming interface when the application calls any application programming interface in any interface library, based on the API call entry point provided to the application.

[0090] In this embodiment, the API call entry points provided to applications are also custom-designed for the mobile operating system. In practical applications, this custom design can be implemented based on the native call entry point provision method in the mobile operating system. For example, the API call interfaces of one or more interface libraries provided to applications in this embodiment can be added to the libEGL library that the application already loads. In the mobile operating system, the libEGL library is natively used to provide call entry points for APIs in various interface libraries to applications. Further examples are not provided here.

[0091] Thus, in this embodiment, for the mobile operating system, custom functions can be simulated as APIs in the interface library, thereby bridging the custom functions in the target dynamic library to the APIs in the interface library used by the application. When the mobile operating system on the first computing end detects that an application is calling any API in any interface library, it automatically calls the call entry point reconfigured for that API in this embodiment. This reconfigured call entry point points to the custom function in the target dynamic library that is functionally compatible with that API.

[0092] In summary, this embodiment provides different solutions for different operating systems to bridge custom functions in the target dynamic library to APIs in the interface library used by the application. This makes the cross-platform GPU invocation mechanism in this embodiment compatible with various types of platforms. Thus, this embodiment supports application operation across multiple platforms without modifying the application's program code, and during cross-platform operation, the cross-platform GPU invocation mechanism improves the application's response efficiency.

[0093] In the above or the following embodiments, a protocol data batch forwarding mechanism is also proposed for the calling end.

[0094] Therefore, in this embodiment, the first computing end can allocate a protocol buffer for the API called by the application according to the function logic of the target function. Based on this, protocol data can be constructed for the API based on the API's interface identifier, the interface parameters set by the application when calling the API, and the attribute information of the protocol buffer. After the protocol data is constructed, it can be stored in the protocol buffer for batch forwarding. In this case, the protocol data will carry the attribute information of the protocol buffer. The called end can prepare a protocol buffer for the received protocol data according to the attribute information of the protocol buffer, thereby processing the received protocol data in sequence.

[0095] In this embodiment, a batch forwarding timing judgment logic is designed in the function logic of the objective function. Based on this, after the first computing end creates the protocol data for the API called by the application, it can monitor whether the unforwarded protocol data corresponding to the application meets the batch forwarding conditions. If so, the unforwarded protocol data corresponding to the application can be batch forwarded. In this way, the protocol data created by the first computing end for the API called by the application can be forwarded to the second computing end through the batch forwarding operation.

[0096] The batch forwarding conditions in this embodiment may include, but are not limited to:

[0097] The cumulative amount of unforwarded protocol data corresponding to the application has exceeded a preset threshold; and / or,

[0098] The application has timing requirements for calling this API.

[0099] During their research, the inventors discovered that different APIs correspond to different protocol data specifications. Most APIs have protocol data specifications of around tens of bytes, but some APIs may have protocol data specifications reaching several megabytes, such as APIs in the OpenGL library that include array parameters like GLITEMAGE. Based on this, in this embodiment, after the first computing terminal creates protocol data for the APIs called by the application, it can count the cumulative amount of unforwarded protocol data from the application. If the cumulative amount exceeds a preset threshold, a batch forwarding operation can be performed. This preset threshold can be flexibly set as needed. Optionally, it can be set according to the bandwidth supported by the network interface card in the network used by the first computing terminal; for example, the preset threshold can be set to 80% of the network bandwidth, etc., without limitation. This allows for full utilization of the network bandwidth.

[0100] During their research, the inventors also discovered that applications have timing requirements for calling certain APIs. For example, an application might call two APIs, API1 and API2, where the execution of API2 depends on the processing result of API1. In this case, the application's call to API1 has a timing requirement; that is, API1 must be executed first before API2 can be executed. To address this, the first computing end can perform a batch forwarding operation immediately after constructing the protocol data for API1, without being subject to the aforementioned cumulative limit. This effectively ensures that the second computing end can call the relevant APIs according to the timing requirements.

[0101] It should be understood that the above-mentioned batch forwarding conditions are exemplary. Other batch forwarding conditions can be set as needed in this embodiment to ensure that the second computing end can correctly call the relevant API according to the application's requirements. This embodiment is not limited to this, and no further examples will be given here.

[0102] As mentioned in the previous embodiments, the called end used by the first computing end can be fixed or dynamically allocated. In this embodiment, when the called end used by the first computing end is fixed, the first computing end can batch forward the unforwarded protocol data corresponding to the application to the fixed called end (i.e., the second computing end in this embodiment). When the called end used by the first computing end is dynamically allocated, the first computing end can batch forward the unforwarded protocol data corresponding to the application to the scheduler in the aforementioned GPU resource pool. The scheduler can decide which computing end in the GPU resource pool to forward this protocol data to based on the scheduling result. Of course, in this case, the unforwarded protocol data corresponding to the application will also be forwarded to the same called end. However, in the case of dynamic allocation, there may be multiple applications using cross-platform GPU calling mechanisms on the first computing end, and the scheduler in the GPU resource pool may allocate different called ends to these multiple applications. Therefore, in this embodiment, the first computing end can also support batch forwarding of unforwarded protocol data corresponding to multiple applications, and the scheduler in the GPU resource pool can distribute these protocol data batch forwarded by the first computing end to the corresponding called ends according to the called ends allocated to different applications.

[0103] In this embodiment, a code segment supporting the protocol data batch forwarding mechanism can be written in the target dynamic library. The first computing terminal can implement the aforementioned protocol data batch forwarding mechanism by executing this code segment. In addition, based on this code segment, when performing batch forwarding operations, the first computing terminal can perform compression processing on the unforwarded protocol data and perform forwarding operations on the resulting compressed packets. This can further reduce the amount of data transmitted over the network and reduce network transmission latency.

[0104] In this way, the protocol data batch forwarding mechanism can effectively reduce the number of interactions between the calling end and the called end, reduce the impact of network transmission on API response efficiency, and thus better ensure the response efficiency of the application under the cross-end GPU calling mechanism.

[0105] Of course, in addition to the protocol batch forwarding mechanism, the direct forwarding mechanism can also be used in this embodiment. That is, after the first computing end creates the protocol data for the API called by the application, it can directly forward the protocol data to the second computing end without caching or waiting. Although this may introduce more network transmission delay, it does not affect the implementation of the cross-end GPU calling mechanism in this embodiment.

[0106] In the embodiments described above or below, the user-defined functions in the target dynamic library may contain function logic in addition to those used to construct protocol data. Several other aspects of function logic are illustrated below.

[0107] In one exemplary aspect:

[0108] In this embodiment, if the API needs to return intermediate processing values ​​to the application, the function logic for constructing the intermediate processing values ​​can be written in a custom function adapted to the API functionality.

[0109] Based on this, if the API called by the application needs to return an intermediate processing value to the application, the first computing end can generate a substitute value for the intermediate processing value to be returned by executing the function logic of the target function; and can return the substitute value to the application; and can also add the substitute value to the protocol data to trigger the second computing end to map the intermediate processing value it generates to the substitute value, so that when the application operates on the substitute value, it responds to the operation according to the corresponding intermediate processing value in the second computing end.

[0110] For example, the `glGenObject` API in the OpenGL library, used to create objects, needs to return the object ID of the created object to the application. In this embodiment, the target function adapted to this API can generate a substitute value and return it to the application, without needing to obtain the actual object ID from the second computing end over the network. The target function can pass this substitute value to the second computing end along with protocol data. After creating the object, the second computing end can map the generated actual object ID to this substitute value. Based on this, the application will use the substitute value to operate on the object by calling the API again or calling other APIs. The second computing end can find the actual intermediate processing value (Object ID) mapped to the substitute value and execute the interface logic of the relevant API according to this actual intermediate processing value.

[0111] In this way, by using the substitute value provided by the custom function, the caller and the callee no longer need to generate intermediate processing values ​​through multiple interactions. Instead, the data consistency between the caller and the callee can be guaranteed through the substitute value without any interaction. This can effectively reduce the number of interactions between the caller and the callee and reduce the impact of network transmission latency on API response efficiency.

[0112] In another exemplary aspect:

[0113] In this embodiment, if the API needs to query the status data of its respective interface library, function logic for recording status data for the interface library can be written in a custom function adapted to the API functionality.

[0114] Therefore, if the interface library used by the application contains APIs that require querying the status of the interface library, then the status data of the interface library to which such APIs belong is recorded according to the function logic of the corresponding custom function in the target dynamic library; after detecting that the application has called such APIs, the recorded status data can be returned to the application according to the function logic of the corresponding custom function.

[0115] For example, the Gluget API in the OpenGL library is used to obtain the current value (i.e., state data) of the OpenGL library's state variables. You can write function logic in the target function of the target dynamic library that is adapted to the API to record the state data of the OpenGL library. Based on this, even if the API has not been called, its corresponding target function has automatically recorded the OpenGL library. In this way, when the application calls the API, its corresponding target function can return the recorded state data to the application, without having to obtain the required state data from a second computing terminal over the network.

[0116] It can be seen that by automatically recording status data for the relevant interface library through custom functions, the number of interactions between the caller and the callee can be effectively reduced, and the impact of network transmission latency on API response efficiency can be reduced.

[0117] In summary, in this embodiment, based on the API's interface functionality, function logic for providing the required return values ​​to the application can be written in the corresponding custom function. This effectively reduces the number of interactions between the caller and the callee due to information synchronization, and reduces the impact of network transmission latency on API response efficiency. It should be understood that the function logic provided above for the custom function is merely exemplary. This embodiment supports writing other function logic in the custom function as needed to reduce the number of interactions between the caller and the callee. This embodiment is not limited to this and will not provide further examples.

[0118] Figure 3 This is a flowchart illustrating a communication method provided as another exemplary embodiment of this application, which can be executed by a first computing terminal in a communication system. (Reference) Figure 3 The method may include:

[0119] Step 300: In response to detecting that an application calls any application programming interface in any interface library, intercept the application's call to the application programming interface, wherein the application programming interface is used to control the graphics processing unit to perform processing tasks;

[0120] Step 301: Construct the protocol data required for execution of the application programming interface;

[0121] Step 302: Forward the protocol data to the second computing terminal to trigger the second computing terminal to call the application programming interface from its own interface library according to the protocol data, so as to use the image processing unit assembled on the second computing terminal to complete the processing task.

[0122] This embodiment proposes a cross-platform GPU invocation mechanism, where the first computing end acts as the invoking end and the second computing end acts as the invoked end. For details on the cross-platform GPU invocation mechanism, please refer to the description in the preceding system embodiment; it will not be repeated here.

[0123] Therefore, a cross-platform GPU invocation mechanism is proposed. A call interception mechanism for application programming interfaces (APIs) is set up in the first computing terminal. Based on this, when the first computing terminal detects an application calling any API from any API library, it will intercept the application's call to the API. Furthermore, the first computing terminal can construct the necessary protocol data for the execution of the API and forward this protocol data to the second computing terminal. This triggers the second computing terminal to call the API from its own provided interface library, thereby utilizing the image processing unit mounted on the second computing terminal to execute the processing task indicated by the application. Accordingly, the first computing terminal no longer directly forwards the application's calls to APIs; instead, it constructs protocol data for APIs in various interface libraries. This protocol data unifies the implementation interface between the first and second computing terminals, enabling the first computing terminal to effectively support various interface libraries and achieve cross-platform GPU invocation by constructing and forwarding protocol data. In this way, cross-platform GPU invocation can be achieved without modification or awareness of the application, thereby improving the application's response efficiency.

[0124] In one alternative embodiment, application programming interfaces that are functionally identical but have inconsistent identifiers in different interface libraries are adapted to the same function in the target dynamic library.

[0125] In an alternative embodiment, step 301 may include:

[0126] Call the target function in the preset target dynamic library that is compatible with the application programming interface;

[0127] Based on the functional logic of the target function, construct the protocol data required for execution of the application programming interface.

[0128] In an optional embodiment, the step of calling a target function in a preset target dynamic library that is compatible with the functionality of the application programming interface may include:

[0129] If the first computing terminal uses a desktop operating system, then the custom functions contained in the target dynamic library are registered as hook functions; for each application programming interface contained in one or more interface libraries loaded by the application, a function matching hook function is found respectively, so as to establish the association between the application programming interface and the hook function for the application.

[0130] Based on the aforementioned association, when the application calls any application programming interface (API) in any API library, the hook function associated with the API is automatically called back.

[0131] In an optional embodiment, the step of calling a target function in a preset target dynamic library that is compatible with the functionality of the application programming interface may include:

[0132] If the first computing terminal uses a mobile operating system, then the application is provided with an entry point for calling one or more application programming interfaces from an interface library;

[0133] The call entry point of any application programming interface provided to the application is set to point to a custom function in the target dynamic library that is adapted to the functionality of the application programming interface;

[0134] Based on the aforementioned call entry point, when the application calls any application programming interface in any interface library, a custom function adapted to the functionality of the application programming interface is automatically invoked.

[0135] In an alternative embodiment, step 301 may include:

[0136] According to the preset forwarding protocol, based on the interface identifier of the application programming interface and the interface parameters set when the application calls the application programming interface, the protocol data required for the execution of the application programming interface is constructed, and the protocol data conforms to the protocol format required by the forwarding protocol;

[0137] Based on this, step 302 may include:

[0138] After the protocol data is constructed, the protocol data is forwarded to the second computing terminal.

[0139] In an optional embodiment, the step of constructing the protocol data required for the execution of the application programming interface (API) based on the interface identifier of the API and the interface parameters set when the application calls the API may include:

[0140] Allocate a protocol buffer for the application programming interface;

[0141] According to the preset forwarding protocol, based on the interface identifier of the application programming interface, the attribute information of the protocol buffer, and the interface parameters set when the application calls the application programming interface, protocol data is constructed for the application programming interface;

[0142] The protocol data is stored in the protocol cache area;

[0143] Based on this, step 302 may include:

[0144] After the protocol data is constructed, if it is detected that the unforwarded protocol data corresponding to the application meets the batch forwarding conditions, the unforwarded protocol data is batch forwarded to forward the protocol data to the second computing terminal.

[0145] In an optional embodiment, the bulk forwarding conditions may include:

[0146] The cumulative amount of unforwarded protocol data corresponding to the application has exceeded a preset threshold, and / or, the application's calls to the application programming interface have timing requirements.

[0147] In an optional embodiment, the method may further include:

[0148] If the application programming interface needs to return an intermediate processing value to the application, then a substitute value is generated for the required intermediate processing value according to the function logic of the target function;

[0149] Return the substitute value to the application;

[0150] The substitute value is added to the protocol data to trigger the second computing terminal to map the intermediate processing value it generates to the substitute value, so that when the application operates on the substitute value, it responds to the operation according to the intermediate processing value.

[0151] In an optional embodiment, the method may further include:

[0152] If the interface library used by the application contains a target application programming interface that requires querying the interface library status, then the status data of the interface library to which the target application programming interface belongs is recorded according to the function logic of the custom function corresponding to the target application programming interface in the target dynamic library.

[0153] After detecting that the application calls the target application editing interface, the recorded status data is returned to the application according to the function logic of the custom function corresponding to the target application programming interface.

[0154] It is worth noting that the technical details of the various embodiments corresponding to the communication method of the first computing terminal mentioned above can be found in the relevant descriptions of the first computing terminal in the foregoing system embodiments. To save space, these details will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0155] Figure 4 This is a flowchart illustrating another communication method provided as an exemplary embodiment of this application. This communication method can be executed by a second computing terminal in a communication system, as shown in the attached diagram. Figure 4 The method may include:

[0156] Step 400: After receiving the protocol data sent by the first computing terminal, parse the application programming interface corresponding to the protocol data. The protocol data is constructed by the first computing terminal after detecting that the application calls the application programming interface.

[0157] Step 401: Call the application programming interface from the interface library provided by the second computing terminal itself;

[0158] Step 402: Based on the protocol data, execute the interface logic corresponding to the application programming interface to control the second computing terminal to execute the processing task indicated by the application when calling the application programming interface.

[0159] This embodiment proposes a cross-platform GPU invocation mechanism, where the first computing end acts as the invoking end and the second computing end acts as the invoked end. For details on the cross-platform GPU invocation mechanism, please refer to the description in the preceding system embodiment; it will not be repeated here.

[0160] Accordingly, the second computing terminal can parse the protocol data sent by the first computing terminal according to the forwarding protocol agreed upon with the first computing terminal, thereby providing cross-terminal GPU call support for applications on the first computing terminal.

[0161] In an alternative embodiment,

[0162] Step 402 may include:

[0163] Parse the interface parameters set by the application when calling the application programming interface from the protocol data;

[0164] From the interface index table, find the interface logic pointed to by the interface pointer corresponding to the application programming interface; wherein, the interface index table contains interface pointers created for each application programming interface in the interface library, and the interface pointers are used to point to the interface logic;

[0165] The interface logic is executed based on the interface parameters.

[0166] In an optional embodiment, the method further includes:

[0167] Create an interface index table for the interface libraries required by the application.

[0168] In one optional embodiment, in the interface index tables corresponding to different interface libraries, the interface pointers corresponding to application programming interfaces with the same function but different identifiers point to the same interface logic.

[0169] In one optional embodiment, the second computing terminal is located in the graphics processing unit resource pool, which includes a scheduler. The scheduler is used to receive the protocol data sent by the first computing terminal and schedule the protocol data to the second computing terminal according to the resource scheduling strategy.

[0170] It is worth noting that the technical details of the various embodiments corresponding to the communication method of the second computing terminal mentioned above can be found in the relevant descriptions of the second computing terminal in the foregoing system embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

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

[0172] Figure 5 This is a schematic diagram of the structure of a computing device provided as another exemplary embodiment of this application. For example... Figure 5 As shown, the computing device may include: memory 50, processor 51, and communication component 52.

[0173] The computing device can serve as the first computing end in the aforementioned communication system. In this case, the processor 51 can be coupled to the memory 50 and the communication component 52 to execute the computer program in the memory 50 for executing the aforementioned communication method executed by the first computing end.

[0174] The computing device can also serve as a second computing terminal in the aforementioned communication system. In this case, the processor 51 can be coupled to the memory 50 and the communication component 52 to execute the computer program in the memory 50 for performing the aforementioned communication method executed by the second computing terminal.

[0175] Furthermore, such as Figure 5 As shown, the computing device also includes other components such as a power supply component 53. Figure 5 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 5 The components shown.

[0176] It is worth noting that the technical details of the above-mentioned embodiments of the computing device can be referred to the relevant descriptions in the foregoing system embodiments and method embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0177] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps in the above method embodiments.

[0178] Accordingly, this application also provides a computer program product, which, when executed, can implement the steps in the above method embodiments.

[0179] The above Figure 5 The memory in a computer is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks.

[0180] The above Figure 5 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0181] The above Figure 5The power supply component provides power to various components within the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0182] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0183] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0184] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0185] These computer program instructions can also be assembled onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0186] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0187] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0188] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A communication method, characterized in that, Applicable to the first computing end, the method includes: In response to detecting that an application calls any application programming interface (API) in any interface library, the application calls to the API are intercepted, the API being used to control the graphics processing unit to perform processing tasks; and the protocol data required for the execution of the API is constructed. The protocol data is forwarded to the second computing terminal to trigger the second computing terminal to call the application programming interface from its own interface library according to the protocol data, so as to use the image processing unit assembled on the second computing terminal to complete the processing task.

2. The method according to claim 1, characterized in that, The protocol data required for the execution of the application programming interface includes: Call the target function in the preset target dynamic library that is compatible with the application programming interface; Based on the functional logic of the target function, construct the protocol data required for execution of the application programming interface.

3. The method according to claim 2, characterized in that, The target function employs a hook function associated with the application programming interface; Calling target functions in a preset target dynamic library that are compatible with the application programming interface includes: If the first computing terminal uses a desktop operating system, then the custom functions contained in the target dynamic library are registered as hook functions; For each application programming interface (API) contained in one or more interface libraries loaded by the application, find the corresponding hook function and establish the association between the API and the hook function for the application. Based on the aforementioned association, when the application calls any application programming interface (API) in any API library, the hook function associated with the API is automatically called back.

4. The method according to claim 2, characterized in that, The target function is a custom function adapted to the functionality of the application programming interface; Calling target functions in a preset target dynamic library that are compatible with the application programming interface includes: If the first computing terminal uses a mobile operating system, then the application is provided with an entry point for calling one or more application programming interfaces from an interface library; The call entry point of any application programming interface provided to the application is set to point to a custom function in the target dynamic library that is adapted to the functionality of the application programming interface; Based on the aforementioned call entry point, when the application calls any application programming interface in any interface library, a custom function adapted to the functionality of the application programming interface is automatically invoked.

5. The method according to claim 1, characterized in that, The protocol data required for the execution of the application programming interface includes: According to the preset forwarding protocol, based on the interface identifier of the application programming interface and the interface parameters set when the application calls the application programming interface, the protocol data required for the execution of the application programming interface is constructed, and the protocol data conforms to the protocol format required by the forwarding protocol.

6. The method according to claim 1, characterized in that, According to a preset forwarding protocol, based on the interface identifier of the application programming interface (API) and the interface parameters set when the application calls the API, the protocol data required for the execution of the API is constructed, including: Allocate a protocol buffer for the application programming interface; According to the preset forwarding protocol, based on the interface identifier of the application programming interface, the attribute information of the protocol buffer, and the interface parameters set when the application calls the application programming interface, protocol data is constructed for the application programming interface; The protocol data is stored in the protocol cache.

7. The method according to claim 6, characterized in that, Forwarding the protocol data to the second computing terminal includes: After the protocol data is constructed, if it is detected that the unforwarded protocol data corresponding to the application meets the batch forwarding conditions, the unforwarded protocol data is batch forwarded to forward the protocol data to the second computing terminal.

8. The method according to claim 7, characterized in that, The batch forwarding conditions include: The cumulative amount of unforwarded protocol data corresponding to the application has exceeded a preset threshold, and / or, the application's calls to the application programming interface have timing requirements.

9. The method according to any one of claims 1-8, characterized in that, Also includes: If the application programming interface needs to return an intermediate processing value to the application, then a substitute value is generated for the required intermediate processing value according to the function logic of the target function; Return the substitute value to the application; The substitute value is added to the protocol data to trigger the second computing terminal to map the intermediate processing value it generates to the substitute value, so that when the application operates on the substitute value, it responds to the operation according to the intermediate processing value.

10. The method according to any one of claims 1-8, characterized in that, Also includes: If the interface library used by the application contains a target application programming interface that requires querying the interface library status, then the status data of the interface library to which the target application programming interface belongs is recorded according to the function logic of the custom function corresponding to the target application programming interface in the target dynamic library. After detecting that the application calls the target application editing interface, the recorded status data is returned to the application according to the function logic of the custom function corresponding to the target application programming interface.

11. The method according to any one of claims 1-8, characterized in that, Application programming interfaces (APIs) that have the same functionality but different identifiers in different interface libraries are adapted to the same function in the target dynamic library.

12. A communication method, characterized in that, Applicable to a second computing terminal, the method includes: After receiving the protocol data sent by the first computing terminal, the application programming interface corresponding to the protocol data is parsed. The protocol data is constructed by the first computing terminal after detecting that the application calls the application programming interface. The application programming interface is called from the interface library provided by the second computing terminal itself; Based on the protocol data, the interface logic corresponding to the application programming interface is executed to control the second computing terminal to execute the processing task indicated by the application when it calls the application programming interface.

13. The method according to claim 12, characterized in that, Based on the protocol data, execute the interface logic corresponding to the application programming interface, including: Parse the interface parameters set by the application when calling the application programming interface from the protocol data; From the interface index table, find the interface logic pointed to by the interface pointer corresponding to the application programming interface; wherein, the interface index table contains interface pointers created for each application programming interface in the interface library, and the interface pointers are used to point to the interface logic; The interface logic is executed based on the interface parameters.

14. The method according to claim 13, characterized in that, The method further includes: Create an interface index table for the interface libraries required by the application.

15. The method according to claim 13, characterized in that, In the interface index tables corresponding to different interface libraries, the interface pointers of application programming interfaces with the same function but different identifiers point to the same interface logic.

16. The method according to any one of claims 12-15, characterized in that, The second computing terminal is located in the graphics processing unit resource pool, which contains a scheduler. The scheduler is used to receive the protocol data sent by the first computing terminal and schedule the protocol data to the second computing terminal according to the resource scheduling strategy.

17. A communication system, characterized in that, Includes a first computing terminal and a second computing terminal; The first computing terminal is configured to intercept the application's call to any application programming interface in any interface library in response to detecting that the application calls any application programming interface in any interface library, wherein the application programming interface is used to control the graphics processing unit to perform processing tasks; Build the protocol data required for execution of the application programming interface; forward the protocol data to the second computing terminal; The second computing terminal is configured to parse the application programming interface corresponding to the protocol data; It calls the application programming interface from its own provided interface library; Based on the protocol data, the interface logic corresponding to the application programming interface is executed to utilize the second computing terminal to perform the processing task.

18. A computing device, characterized in that, Includes memory, processor, and communication components; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for performing the communication method according to any one of claims 1-16.

19. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by one or more processors, the one or more processors perform the communication method according to any one of claims 1-16.

20. A computer program product, characterized in that, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the communication method according to any one of claims 1-16.

Images