Graphics device invocation methods and apparatuses, execution methods and apparatuses, graphics device computing systems

Abstract

The application discloses a graphics device calling method and device, an execution method and device, and a graphics device computing system, relates to the technical field of computers, and comprises the following steps: intercepting a calling request, wherein the calling request comprises a request identifier and calling parameters; determining the calling type of the calling request according to the request identifier; when the calling type is a first calling type, generating a calling command according to the calling parameters and the request identifier; the first calling type is a request requiring the graphics device to execute a graphics task; and sending the calling command to a server, so that the server calls the graphics device according to the calling command, executes the graphics task corresponding to the calling command, and returns an execution result. The method solves the problem that a calling request cannot be intercepted because the calling request does not pass through a graphics computing application programming interface.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a graphics device invocation method and apparatus, an execution method and apparatus, and a graphics device computing system. Background Technology

[0002] As graphics devices are increasingly used in scenarios such as graphics rendering and parallel computing, the demand for flexibility in accessing graphics devices is also increasing.

[0003] When a client executes a graphics device call, the application typically initiates the call through the Graphics Application Programming Interface (API). The user-space driver generates a graphics device call request based on this API and submits it to the Direct Rendering Manager (DRM) via input / output control (ioctl) calls. The DRM then invokes the graphics device to perform the task based on the call request. When the client does not have an executable graphics device and a remote graphics device call is required, the API call is usually intercepted and forwarded to a remote server for processing.

[0004] However, when executing graphics device calls, there are cases where the application does not go through the graphics computing API, but directly generates a call request to DRM and hands the request over to DRM for processing via ioctl. In this scenario, since it does not go through the graphics computing API, the API interception scheme has difficulty in obtaining such requests, and therefore the corresponding graphics task is difficult to forward to the remote server for processing. Summary of the Invention

[0005] This application aims to provide a graphics device invocation method and apparatus, an execution method and apparatus, and a graphics device computing system to solve the problem that existing invocation requests do not go through the graphics computing API, making it difficult for API interception schemes to obtain such requests and making it difficult to forward the corresponding graphics tasks to the remote server for processing.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a method for invoking a graphics device, applied to a user device, the method comprising: Intercept the call request; the call request is a request submitted by the user equipment through input / output control call for invoking the graphics device; the call request includes a request identifier and call parameters; Based on the request identifier, determine the invocation type of the invocation request; When the call type is the first call type, a call command is generated based on the call parameters and the request identifier; the first call type is a request to call the graphics device to perform a graphics task; The invocation command is sent to the server so that the server can invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

[0007] Secondly, embodiments of this application provide a graphics device execution method, applied to a server, the method comprising: Receive a call command sent by a user equipment; the call command is generated by the user equipment based on the call request from the graphics device; The graphics device is invoked according to the invocation command to execute the graphics task corresponding to the invocation command; The execution result of the graphics task is obtained and sent to the user device.

[0008] Thirdly, embodiments of this application provide a graphics device invocation apparatus, applied to a user equipment, the graphics device invocation apparatus comprising: The user-mode interception module is used to intercept call requests; the call request is a request submitted by the user device through input / output control to invoke the graphics device; the call request includes a request identifier and call parameters; A selective processing module is used to determine the invocation type of the invocation request based on the request identifier, and when the invocation type is a first invocation type, to generate an invocation command based on the invocation parameters and the request identifier; the first invocation type is a request that needs to invoke the graphics device to perform a graphics task; An execution module is used to send the invocation command to the server so that the server can invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

[0009] Fourthly, embodiments of this application provide a graphics device execution apparatus, applied on a server, the graphics device execution apparatus comprising: A request receiving module is used to receive a call command sent by a user device; the call command is generated by the user device based on the call request from the graphics device. The request execution module is used to invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command; The request feedback module is used to obtain the execution result of the graphics task and send it to the user device.

[0010] Fifthly, embodiments of this application provide a graphics device computing system, including a user device and a server; The user equipment is used to execute the graphics device invocation method described in any one of the first aspects; The server is used to execute the graphics device execution method described in any of the second aspects.

[0011] In the embodiments of this application, by intercepting graphics device call requests submitted via input / output control calls on the client side, graphics device call requests initiated directly to the direct rendering manager can also be captured, avoiding the problem of call requests not being intercepted due to not going through the graphics computing application programming interface. Furthermore, by filtering the first call type through request identifiers, only requests that need to invoke the graphics device to perform graphics tasks are converted into call commands and sent to the remote server, reducing invalid communication caused by non-critical call requests. Simultaneously, by abstracting the original graphics device call request through call commands, the coupling between the client-side call format and the remote server-side execution format can be reduced, improving the adaptability of the remote graphics device call scheme.

[0012] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating the steps of a graphics device invocation method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the steps of a graphics device execution method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the steps of a graphics device invocation and execution method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a command invocation structure provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a graphics device calling device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a graphics device execution device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a graphics device computing system provided in an embodiment of this application. Detailed Implementation

[0015] The embodiments of this application will now be described in detail. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0016] When a client application invokes a graphics device, it typically initiates a graphics processing request via the graphics computing API. The user-space driver then generates a graphics device invocation request targeting the DRM based on this request and submits it to the DRM via ioctl. The DRM then further invokes the local graphics device to execute the corresponding graphics task. However, there are also cases where the application bypasses the graphics computing API and directly generates a graphics device invocation request targeting the DRM, submitting it to the DRM for processing via ioctl.

[0017] However, in remote graphics device invocation scenarios, if application calls are intercepted only at the graphics computing API level, it becomes difficult to capture graphics device invocation requests submitted directly via ioctl without going through the graphics computing API. This results in such requests not being effectively forwarded to the remote server for processing. Furthermore, forwarding all ioctl calls to the remote server increases unnecessary communication overhead. Therefore, this application provides a graphics device invocation method that intercepts and classifies graphics device invocation requests on the client side, and sends the invocation commands that need to be executed by the remote graphics device to the remote server, whereby the remote server invokes the graphics device to execute the corresponding graphics task.

[0018] like Figure 1 As shown, this application embodiment provides a graphics device invocation method applied to a user device, the method including steps 101-104.

[0019] Step 101: Intercept the call request; the call request is a request submitted by the user device through input / output control call to invoke the graphics device; the call request includes a request identifier and call parameters.

[0020] In this embodiment, intercepting the call request involves acquiring and taking over the request before it enters the local graphics device driver processing, when the user device submits a call request to the graphics device via an input / output control call. The request identifier characterizes the graphics device operation type corresponding to the call request, specifying the operation the call request wants the graphics device to perform. The request identifier can be a device code from an input / output control call or other identifiers that can distinguish different graphics device operations. The call parameters characterize the data required to execute the graphics device operation corresponding to the request identifier, specifying which specific data is needed to execute the operation.

[0021] For example, a user device (User Device) can intercept input / output control calls through function hijacking or dynamic link library substitution. When an application initiates an input / output control call to create a buffer, the User Device can intercept the call and obtain the request identifier and call parameters. For instance, the request identifier could be a buffer creation request identifier; the call parameters could include the size of the buffer to be created, the buffer handle, and other parameters. After obtaining the request identifier and call parameters, the User Device can determine that the call request is a graphics device call request for creating a buffer and generate the corresponding call command based on the request identifier and call parameters in subsequent steps.

[0022] Step 102: Determine the invocation type of the invocation request based on the request identifier.

[0023] In this embodiment, the call type is used to distinguish whether the call request needs to be further generated into a call command and sent to a remote server for processing. If the call request involves processes such as resource management, task submission, task waiting, or data synchronization required for the graphics device to perform graphics tasks, then the call request can be identified as the first call type.

[0024] For example, after intercepting a call request, the request identifier in the call request is obtained. If the request identifier is a buffer creation request identifier, it indicates that the call request is for requesting the creation of a buffer. Since the buffer is a resource required by the graphics device before performing graphics tasks, the call request can be determined to be a call request that requires the participation of a remote graphics device based on the request identifier, and the call type of the call request can be determined as the first call type.

[0025] Step 103: When the call type is the first call type, generate a call command based on the call parameters and request identifier; the first call type is a request that needs to call the graphics device to perform a graphics task.

[0026] In this embodiment, the first invocation type is used to characterize invocation requests that require processing by the graphics device. This type of invocation request is not limited to requests that directly submit computing tasks to the graphics device; it can also include resource preparation requests, address configuration requests, task waiting requests, and data synchronization requests required for the graphics device to execute graphics tasks. In other words, as long as the invocation request is related to the core processing flow required for the graphics device to execute graphics tasks, it can be identified as the first invocation type. The invocation command is a command regenerated by the user device based on the invocation request, which can be recognized and processed by the remote server.

[0027] For example, if the request identifier is a buffer creation request identifier, it means that the call request is used to request the creation of a buffer. In this case, the user equipment can determine that a buffer creation command needs to be generated based on the request identifier, and extract data such as the size of the buffer to be created and the buffer handle based on the call parameters in the call request, thereby generating the corresponding call command.

[0028] For example, when the call parameters include the size and handle of the buffer to be created, the user device can convert the request identifier into a buffer creation command identifier in the call command, and write the buffer size and handle into the call command. Thus, the buffer creation call request, originally directed to the local graphics device driver, is converted into a buffer creation call command that the remote server can recognize, and the remote server then calls the graphics device to create the corresponding buffer.

[0029] Step 104: Send the call command to the server so that the server can invoke the graphics device according to the call command to execute the graphics task corresponding to the call command.

[0030] In this embodiment, the server is a device or system that is communicatively connected to a user device and capable of invoking a graphics device to execute graphics tasks. The server may have a graphics device deployed on it or be connected to a graphics device, and is used to receive invocation commands sent by the user device, and invoke the graphics device to execute corresponding processing based on the invocation commands. The graphics device is a hardware device used to execute graphics processing tasks, parallel computing tasks, or tasks related to graphics resource management. It may include a graphics processor, and may also include other hardware resources capable of responding to graphics device invocation requests and executing corresponding graphics tasks. A graphics task is a task that needs to be executed or participated in by the graphics device. A graphics task may include not only direct task processing flows such as task submission and task execution waiting, but also processing flows such as buffer creation, virtual address configuration, buffer data transmission, and buffer synchronization required before and after the graphics device executes the task.

[0031] For example, after the user equipment generates a call command based on the buffer creation request identifier and call parameters in the aforementioned steps, it can send the call command to the server. After receiving the call command, the server calls the graphics device on the server side to create the corresponding buffer according to the call command.

[0032] For example, if the call command is a task submission type call command, the server can use this call command to invoke the graphics device to execute the corresponding computing task or graphics processing task. If the call command is a task waiting type call command, the server can invoke the graphics device to obtain the execution status or execution result of the corresponding graphics task.

[0033] In summary, by intercepting graphics device call requests submitted via input / output control calls on the client side, even graphics device call requests initiated directly by the direct rendering manager can be captured, avoiding the problem of uninterceptable requests that do not pass through the graphics computing application programming interface. Furthermore, filtering the first call type by request identifier, only requests that require calling the graphics device to perform graphics tasks are converted into call commands and sent to the remote server, reducing invalid communication caused by non-critical call requests. Simultaneously, abstracting the original graphics device call request through call commands reduces the coupling between the client-side call format and the remote server-side execution format, improving the adaptability of the remote graphics device call scheme.

[0034] like Figure 2 As shown, this application embodiment provides a graphics device execution method applied to a server, the method including steps 201-203.

[0035] Step 201: Receive the call command sent by the user device; the call command is generated by the user device based on the call request from the graphics device.

[0036] In this embodiment, receiving a call command sent by the user equipment is the process by which the server obtains the call command from the user equipment, so that the server can subsequently determine whether to invoke the graphics device to perform a specific task based on the call command. The server can receive the call command through network communication, such as receiving the call command sent by the user equipment through a socket connection.

[0037] For example, a user device intercepts a graphics device call request for creating a buffer. The request identifier is a buffer object creation identifier, and the call parameters include the size of the buffer to be created and a buffer handle. The user device generates a corresponding call command based on the graphics device call request, carrying data such as the buffer size and handle in the call command. Subsequently, the call command is sent to the server. Upon receiving the call command, the server can then invoke the graphics device to create the corresponding buffer in subsequent steps.

[0038] For example, if the user device intercepts a graphics device call request that is a task submission request, the user device converts it into a task submission-related call command and sends it to the server along with the data required for task submission. After receiving the call command, the server can invoke the graphics device to perform the corresponding task submission process in subsequent steps.

[0039] Step 202: Invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

[0040] In this embodiment, after receiving a call command from the user equipment, the server identifies the call command, determines the graphics device operation corresponding to the call command, and provides the data required to execute the graphics device operation to the graphics device, enabling the graphics device to execute the corresponding graphics task. The call command instructs the server which graphics task to execute. The data carried in the call command supports the graphics device in executing that graphics task. For example, the call command may instruct the server to call the graphics device to create a buffer, configure a virtual address, submit a graphics task, wait for the graphics task to complete, or synchronize buffer data, etc.

[0041] For example, after receiving a buffer creation call command from the user device, the server can determine the current buffer creation task that needs to be performed based on the command, and call the graphics device to create the corresponding buffer as needed, based on the required buffer size and handle data.

[0042] For example, after receiving a task submission command from the user device, the server determines that task submission processing needs to be performed, and calls the graphics device to execute the corresponding graphics task based on the task submission data and the task data size. Thus, the actual execution of the graphics task occurs on the server-side graphics device, while the user device only needs to generate and send the corresponding command.

[0043] Step 203: Obtain the execution result of the graphics task and send it to the user device.

[0044] In this embodiment, the execution result of the graphics task is the processing result obtained by the graphics device after executing the graphics task corresponding to the invocation command. This execution result may include whether the graphics task was executed successfully, the execution status of the graphics task, resource information returned by the graphics device, task completion information, and data synchronization results. After invoking the graphics device to execute the corresponding graphics task, the server receives or reads the processing result returned by the graphics device. After the server sends the execution result to the user device, the user device can return the corresponding invocation result to the application based on the execution result.

[0045] For example, upon receiving a buffer creation command, the server invokes its graphics device to create the corresponding buffer. If the graphics device successfully creates the buffer, the server can obtain an execution result indicating successful buffer creation. This result may include the buffer creation status and the buffer handle returned by the graphics device. The server then sends this execution result to the user device, enabling the user device to return a successful buffer creation result to the application based on this result.

[0046] For example, after receiving the task submission command, the server reads the corresponding length of task submission data based on the task data size and calls the graphics device to execute the corresponding graphics task. After the graphics device completes the task submission process, the server can obtain the task submission result, such as a successful task submission status or a task identifier, and send the task submission result to the user device.

[0047] In summary, the server can receive the invocation command generated by the user device based on the graphics device invocation request, and then invoke the server-side graphics device to execute the corresponding graphics task according to the invocation command. Finally, the execution result of the graphics task is returned to the user device. Therefore, even when the user device does not have a local graphics device or does not directly use a local graphics device, it can still complete the graphics task processing with the help of the server-side graphics device, realizing the remote execution of graphics device invocation requests. This reduces the dependence on the user device's local graphics hardware resources and improves the adaptability and availability of graphics device invocation in remote execution scenarios.

[0048] Figure 3 This is a flowchart illustrating the interaction between the user device and the server in the graphics device invocation and execution method provided in this application embodiment, as follows: Figure 3 As shown, the method includes steps S301 to S308.

[0049] Step 301: The user equipment intercepts the call request, which includes a request identifier and call parameters.

[0050] In this embodiment, the user equipment can intercept a request to invoke a graphics device when an application submits such a request via input / output control calls. This interception occurs before the request enters the local graphics device processing flow. When an application initiates a graphics device call request, such as buffer creation, virtual address configuration, task submission, or task waiting, the user equipment can obtain the request identifier and call parameters from the request. This allows it to subsequently determine whether the request needs to be converted into a call command to be sent to the server based on the request identifier.

[0051] Optionally, in the embodiments of this application, step 301 includes sub-steps 3011 to 3013.

[0052] Step 3011: Obtain the device identifier from the call request; the device identifier is used to characterize the device type pointed to by the call request.

[0053] In this embodiment, the device identifier is information used in the call request to indicate the called device. When a user device submits a call request via an input / output control call, the call request typically points to a specific device; the device identifier is used to characterize whether the call request points to a graphics device, a general input / output device, or another type of device. The device identifier may include a device file identifier, a device handle, or other information that can distinguish the device type.

[0054] Step 3012: When the device identifier matches the preset graphics device identifier, determine that the call request is a call request for the graphics device.

[0055] In this embodiment, the preset graphics device identifier is a pre-set identifier used to identify the graphics device. After the user device obtains the device identifier in the call request, it can match the device identifier with the preset graphics device identifier; if the two match, it means that the call request points to the graphics device, and the call request can be identified as a call request for the graphics device; if the two do not match, it means that the call request is not a call request for the graphics device, and the original processing path can continue to be processed.

[0056] Step 3013: Set up an interception interface and intercept the call request through the interception interface.

[0057] In this embodiment, the interception interface is used to obtain the call request before it is processed by the original processing logic. The interception interface can be implemented through dynamic link library replacement, function hijacking, or other methods.

[0058] For example, the user equipment can pre-configure an interception interface for intercepting input / output control calls. When an application initiates an input / output control call, the interception interface first captures the call. The user equipment obtains a device identifier from the call request; for example, this device identifier indicates that the call request points to the rendering device corresponding to the graphics device. The user equipment matches this device identifier with a preset graphics device identifier. If they match, it indicates that the call request is directed to the graphics device. At this point, the user equipment can continue to obtain the request identifier and call parameters from the call request and determine the call type in subsequent steps. For example, if the call request further corresponds to graphics device-related operations such as buffer creation, virtual address configuration, task submission, or task waiting, the user equipment can continue to execute subsequent classification and call command generation processes.

[0059] In summary, the user equipment can first obtain the corresponding call requests for input / output control calls through the interception interface, and then determine whether the call request points to a graphics device based on the device identifier. This avoids mistakenly treating non-graphics device call requests as graphics device call requests, thereby improving the accuracy of interception processing. Furthermore, performing subsequent classification and command conversion only on call requests related to the graphics device helps reduce the processing overhead caused by irrelevant call requests, improving the stability and processing efficiency of the remote graphics device call process.

[0060] Step 302: The user equipment determines the invocation type of the invocation request based on the request identifier.

[0061] In this embodiment, the request identifier characterizes the graphics device operation corresponding to the call request. Based on the request identifier, it is determined whether the graphics device operation belongs to the processing flow required for graphics task execution, thereby determining the call type of the call request. For example, if the request identifier corresponds to operations such as buffer creation, virtual address configuration, task submission, task waiting, buffer data transmission, or buffer synchronization, it indicates that the call request is related to the core flow required for the graphics device to execute the graphics task, and the call request is determined to be a first call type. If the request identifier corresponds to operations such as context management, buffer list management, or metadata query that do not require the remote graphics device to actually execute the graphics task, the call request is determined to be a second call type.

[0062] Optionally, in this embodiment of the application, step 302 includes sub-steps 3021 to 3022.

[0063] Step 3021: Based on the request identifier, match the processing category corresponding to the request in the preset call classification table; the preset call classification table is used to record the correspondence between the request identifier and the processing category.

[0064] In this embodiment, after the user equipment obtains the request identifier in the call request, it can look up the processing category corresponding to the request identifier in a preset call classification table to determine how the call request should be processed subsequently. This preset call classification table is not limited to a specific data table format; it can also be a mapping relationship, a configuration file, or other data structure that can record the correspondence between request identifiers and processing categories. The processing category is the type of processing flow corresponding to the call request. The processing category is a more specific classification result obtained based on the request identifier, used to indicate whether the call request corresponds to resource management, task submission, task waiting, data synchronization, or other processing flows; the call type is a further determined processing result based on the processing category, used to indicate whether the call request belongs to the first call type that requires generating a call command and sending it to the server for processing.

[0065] Step 3022: When the processing category meets the preset first category conditions, the call type of the call request is determined as the first call type; the preset first category conditions include: the processing category belongs to the category that needs to call the graphics device to perform graphics tasks.

[0066] In this embodiment, the preset first type of condition can be understood as a preset judgment condition used to determine whether a call request belongs to a first call type. If the processing category corresponding to the call request belongs to the processing category required by the graphics device to perform a graphics task, then the processing category can be considered to meet the preset first type of condition, and the call type of the call request can be determined as the first call type. For example, processing categories such as resource management, task execution, task waiting, and data synchronization can all belong to the processing categories required by the graphics device to perform a graphics task.

[0067] For example, after a user device intercepts a call request, it obtains the request identifier from the call request. If the request identifier is a buffer creation request identifier, the user device can look up the processing category corresponding to the buffer creation request identifier in a preset call classification table. If the preset call classification table records a resource management class corresponding to the buffer creation request identifier, the user device can determine that the processing category of the call request is the resource management class. Since the buffer is a resource required by the graphics device before executing graphics tasks, and the resource management class belongs to the processing category that needs to call the graphics device to execute graphics tasks, this processing category meets the preset first category condition, and the user device can determine the call type of the call request as the first call type.

[0068] For example, if the request identifier in the call request is a task submission request identifier, the user device can match the task execution class in the preset call classification table. Since task submission requires the graphics device to execute the corresponding graphics task, the task execution class belongs to the processing category that requires calling the graphics device to execute the graphics task. Therefore, this processing category meets the preset first category condition, and the user device can determine the call request as the first call type. Correspondingly, if the request identifier corresponds to a processing category such as context management, buffer list management, or metadata query, and this processing category does not belong to the processing category required by the graphics device to execute the graphics task, then the call request can not be determined as the first call type.

[0069] In summary, the user equipment can first match the processing category corresponding to the call request based on the request identifier, and then determine the call type of the call request based on whether the processing category meets the preset first-category condition. This avoids directly generating call commands for all call requests and sending them to the server, instead identifying only call requests related to the graphics device performing graphics tasks as the first call type. This reduces unnecessary remote communication and server-side processing overhead, improves the accuracy of call request classification and processing, and enhances the execution efficiency of remote graphics device calls.

[0070] Step 303: When the user equipment determines that the call type is the first call type, it generates a call command based on the call parameters and the request identifier.

[0071] In this embodiment of the application, after the user equipment determines that the call type of the call request is the first call type, it can determine the command type of the call command to be generated according to the request identifier in the call request, and determine the command data to be carried in the call command according to the call parameters in the call request, thereby generating a call command that can be recognized and processed by the server.

[0072] Optionally, in the embodiments of this application, step 303 includes sub-steps 3031 to 3034.

[0073] Step 3031: Determine the command type corresponding to the request identifier according to the preset correspondence; the preset correspondence includes the correspondence between the request identifier and the command type.

[0074] In this embodiment, the preset correspondence is a pre-set conversion relationship used to record the correspondence between the request identifier in the call request and the command type in the call command. After obtaining the request identifier of the call request, the user equipment can determine which type of call command needs to be generated based on the preset correspondence. That is, the preset correspondence is used to convert the request identifier in the original call request into a command type that the server can recognize. The command type is used to characterize the type of graphics task that the server needs to execute based on the call command. The command type can correspond to different graphics tasks such as buffer creation, virtual address configuration, task submission, task waiting, buffer data transmission, or buffer synchronization.

[0075] Step 3032: Based on the command type, determine the parameter items required to execute the graphics task corresponding to the command type.

[0076] In this embodiment, the parameter items are used to characterize the data items required when executing the graphics task corresponding to the command type. The parameter items can be different for different command types. For example, the parameter items corresponding to the buffer creation command type may include buffer size, buffer handle, etc.; the parameter items corresponding to the task submission command type may include task submission data, task data size, etc.; and the parameter items corresponding to the task wait command type may include task identifier, wait time, etc.

[0077] Step 3033: Extract the command parameters corresponding to the parameter items from the call parameters.

[0078] In this embodiment, command parameters are used to characterize the specific data extracted from the call parameters based on the parameter items. Parameter items specify which data is needed, and command parameters specify the specific content of this data. The user equipment can determine the required parameter items based on the command type, extract the corresponding command parameters from the call parameters based on these parameter items, and combine the command type and command parameters to generate the call command.

[0079] Step 3034: Generate a calling command based on the command type and command parameters; the command type is used to characterize the graphics task that the server needs to execute, and the command parameters are used to characterize the data required to execute the graphics task.

[0080] For example, a user device intercepts a task submission request, which includes a request identifier and call parameters. The user device determines the task submission command type corresponding to the request identifier based on a preset mapping. Then, based on the task submission command type, the user device determines the parameters required for task submission, including task submission data and task data size. Next, the user device extracts the corresponding command parameters from the call parameters based on these two parameters. Finally, the user device generates a task submission call command based on the task submission command type, the extracted task submission data, and the task data size. Upon receiving this task submission call command, the server invokes the graphics device to perform the corresponding task submission processing according to the call command.

[0081] For example, if the user equipment intercepts a buffer creation call request, it can determine the corresponding command type as a buffer creation command type based on a preset correspondence, and further determine that the parameters corresponding to this command type include the buffer size and the buffer handle. After extracting the command parameters corresponding to the buffer size and the buffer handle from the call parameters, the user equipment can generate a buffer creation class call command based on the buffer creation command type and the corresponding command parameters.

[0082] For example, such as Figure 4 As shown, if the user equipment intercepts a buffer creation call request, it can determine the command type corresponding to the call request as a buffer creation command type based on a preset correspondence. The buffer creation call command generated by the user equipment can include a message header and a payload. The message header can include a command identifier (cmd) and a command data size (size1); the command identifier (cmd) can be a buffer creation command identifier, for example... Figure 4The `VGPU_IOCTL_GEM_CREATE` parameter in the command data structure can be used to characterize the length of the payload data, such as the size of the payload structure for creating a buffer. The payload can include command parameters required to execute the buffer creation task, such as the buffer size (`size2`), the buffer handle (`handle`), and other fields. After extracting the command parameters such as the buffer size (`size2`) and the buffer handle (`handle`) from the call parameters, the user device can write the buffer creation command identifier into the message header and write the command parameters such as the buffer size and buffer handle into the payload, thereby generating a buffer creation class call command.

[0083] In summary, the user device can first determine the command type recognizable by the server based on the request identifier, then determine the required parameters based on the command type, and extract the corresponding command parameters from the call parameters, thereby generating a call command with a clear structure and complete parameters. This ensures that different types of graphics device call requests are converted into corresponding call commands, improving the accuracy of command conversion; furthermore, it avoids sending irrelevant data from the call parameters to the server, reducing data redundancy in the call commands and improving the communication efficiency between the user device and the server.

[0084] Step 304: The user equipment sends the call command to the server so that the server can call the graphics device according to the call command to execute the graphics task corresponding to the call command.

[0085] In this embodiment, after generating a call command, the user equipment can send the call command to the server via network communication. The server can determine the graphics task to be executed based on the command type and obtain the data required to execute the graphics task based on the command parameters.

[0086] Step 305: The server receives the call command.

[0087] In this embodiment, the server receives a call command sent by the user device and uses this command as the basis for subsequent calls to the graphics device. This call command is generated by the user device based on the graphics device's call request, and it may carry a command type and command parameters. The command type represents the graphics task that the server needs to invoke the graphics device to perform, and the command parameters represent the data required to perform that graphics task. After receiving the call command, the server can proceed with the subsequent parsing and execution process, thereby transferring the graphics device call request from the user device to the server for processing.

[0088] Step 306: The server invokes the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

[0089] In this embodiment, after receiving a call command, the server can determine the graphics task to be executed based on the command type in the call command, and determine the data required to execute the graphics task based on the command parameters in the call command. For example, if the call command is a buffer creation call command, the server can call the graphics device to create the corresponding buffer; if the call command is a task submission call command, the server can call the graphics device to perform the corresponding task submission processing based on the task submission data and the task data size.

[0090] Optionally, in the embodiments of this application, step 306 includes sub-steps 3061 to 3063.

[0091] Step 3061: Parse the calling command to obtain the command type and command parameters; the command type is used to characterize the graphics task corresponding to the calling command, and the command parameters are used to characterize the data required to execute the graphics task.

[0092] Step 3062: Based on the command type, match the corresponding graphical task in the preset task mapping relationship; the preset task mapping relationship is used to record the mapping relationship between command type and graphical task.

[0093] Step 3063: Execute the graphical task corresponding to the command call according to the command parameters.

[0094] In this embodiment, the command type is the information in the call command used to indicate what kind of graphics task the server needs to execute. After parsing the call command, the server can determine the target graphics task corresponding to the call command based on the command type. For example, the command type can be used to characterize a buffer creation task, a virtual address configuration task, a task submission task, a task waiting task, a buffer data transfer task, or a buffer synchronization task. The command parameters are the data in the call command used to support the graphics device in executing the target graphics task. After determining the target graphics task, the server can combine the command parameters to call the graphics device to execute the target graphics task. For example, when the target graphics task is a buffer creation task, the command parameters may include data such as the buffer size and buffer handle; when the target graphics task is a task submission task, the command parameters may include data such as task submission data and task data size.

[0095] For example, after receiving a call command from a user device, the server parses the command to obtain the command type and command parameters. If the command type represents a task submission task, the server can match the target graphics task as a task submission task in a preset task mapping relationship based on the command type. Further, the server can invoke the graphics device to execute the task submission task based on the task submission data and task data size in the command parameters. As another example, if the command type represents a buffer creation task, the server can determine that the target graphics task is a buffer creation task based on the command type, and invoke the graphics device to create the corresponding buffer based on the buffer size, buffer handle, and other data in the command parameters.

[0096] In summary, the server can accurately determine the target graphics task to be executed by the graphics device based on the command type, and obtain the data required to execute the target graphics task through command parameters. This allows the server to accurately parse and execute the command. On the one hand, this improves the accuracy of the server's invocation of graphics devices to execute graphics tasks; on the other hand, it allows different types of commands to be processed according to their corresponding graphics tasks and parameters, improving the standardization and efficiency of the remote graphics device invocation process.

[0097] Step 307: Obtain the execution result of the graphics task and send it to the user device.

[0098] In this embodiment, after the server invokes the graphics device to execute the graphics task corresponding to the invocation command, it can obtain the execution result returned by the graphics device and send the execution result to the user device. The execution result includes the execution status of the graphics task, resource creation result, task submission result, task completion result, or data synchronization result, etc.

[0099] Optionally, in this embodiment of the application, step 308 is included after step 304.

[0100] Step 308: Obtain the task execution result sent by the server; the task execution result is the result obtained by the server calling the graphics device to execute the graphics task corresponding to the calling command according to the calling command.

[0101] In this embodiment, the task execution result is the processing result generated by the graphics device on the server side after completing the corresponding graphics task. After obtaining the task execution result, the user device can generate a return result corresponding to the original call request based on the task execution result, and provide the return result to the application that initiated the call request.

[0102] For example, if the user device sends a buffer creation command to the server, the server can obtain the buffer creation result after invoking the graphics device to create the buffer. This result may include information such as whether the buffer was created successfully and the buffer handle. After obtaining the task execution result sent by the server, the user device can return the corresponding call result to the application based on the buffer creation result.

[0103] For example, if the user device sends a task submission command to the server, the server can invoke the graphics device to perform the task submission process based on the task submission data and task size in the command. After the graphics device completes the task submission, the server can obtain the task execution result, such as the task submission success status, task identifier, or task execution status, and send the task execution result to the user device. After obtaining the task execution result, the user device can return the corresponding call result to the application.

[0104] In summary, the user device can obtain the task execution result obtained by the server-side graphics device after executing the graphics task, and respond to the original call request based on the task execution result. In this way, the application can still obtain the graphics device call result according to the original call logic, without needing to know that the graphics task is actually executed in the server-side graphics device.

[0105] Optionally, in this embodiment of the application, step 309 is included after step 302.

[0106] Step 309: When the call type is the second call type, generate the preset return result of the call request; the second call type is a request that does not require calling the graphics device to perform graphics tasks.

[0107] In this embodiment, the second call type is a call request type that does not require sending to the server or invoking the graphics device to actually execute the graphics task. Although this type of call request may belong to a graphics device-related call flow, it does not involve core processing flows requiring graphics device participation, such as buffer creation, virtual address configuration, task submission, task waiting, data transmission, or data synchronization. Therefore, the user device does not need to generate a call command for this type of call request. The preset return result is the return result directly generated by the user device for the call request of the second call type. This preset return result is used to return a call completion status, a preset query result, or other results that meet the return requirements of the call request to the application, thereby allowing the application's call flow to continue execution. In other words, for call requests that do not require a remote graphics device to execute the graphics task, the user device can complete the local response by generating a preset return result.

[0108] For example, if the user device determines, based on the request identifier, that the call request corresponds to a processing flow such as context management, buffer list management, or metadata query, and that the processing flow does not require the graphics device to perform graphics tasks, then the call request can be identified as the second call type. In this case, the user device may not generate a call command or send the call request to the server, but instead directly generate a preset return result corresponding to the call request and return the preset return result to the application so that the application can continue with subsequent processing flows.

[0109] In summary, user devices can respond locally to calls that do not require invoking the graphics device to perform graphics tasks, avoiding sending such calls to the server and thus reducing unnecessary remote communication and server processing overhead. Furthermore, by returning preset results to the application, the original application call flow can be maintained, improving the compatibility and execution efficiency of remote graphics device invocation.

[0110] Optionally, in this embodiment of the application, step 309 further includes sub-step 3091.

[0111] Step 3091: The preset return result includes a preset success status; the preset success status is used to indicate that the call request corresponding to the second call type does not need to be converted into a call command and forwarded to the server.

[0112] In this embodiment, the preset success status is a success return status pre-set by the user equipment for a call request of the second call type. This preset success status indicates that the call request has been responded to on the user equipment side, and there is no need to invoke the graphics device to execute the corresponding graphics task. In other words, for call requests that do not require remote graphics device involvement, the user equipment can directly generate a preset return result containing the preset success status and return this preset return result to the application, so that the application considers the call request to have been processed normally.

[0113] For example, if the call request corresponds to a processing flow that does not require the graphics device to perform graphics tasks, such as context management, buffer list management, or metadata query, the user device can classify the call request as a second call type. In this case, the user device does not need to convert the call request into a call command and send it to the server; instead, it can directly generate a preset return result containing a preset success status. For example, the user device can return status information indicating a successful call to the application, allowing the application to continue executing subsequent processes.

[0114] In summary, the user device can directly return a preset success status for the second type of call request, avoiding sending call requests that do not require actual execution by the graphics device to the server, thereby reducing unnecessary communication and server processing overhead. Simultaneously, by returning a preset success status, the continuity of the application's original call flow can be maintained, reducing the impact of remote graphics device calls on the application's runtime logic.

[0115] This application provides a graphics device invocation device 40 applied to a user device, such as... Figure 5 As shown, the graphics device invocation device 40 includes: User-mode interception module 401 is used to intercept call requests; the call request is a request submitted by the user device through input / output control calls to invoke the graphics device; the call request includes a request identifier and call parameters.

[0116] The selective processing module 402 is used to determine the call type of the call request based on the request identifier. When the call type is the first call type, it generates a call command based on the call parameters and the request identifier. The first call type is a request that needs to call the graphics device to perform a graphics task.

[0117] The execution module 403 is used to send the call command to the server so that the server can call the graphics device according to the call command to execute the graphics task corresponding to the call command.

[0118] Optionally, the graphics device invocation device further includes: The second processing module is used to generate a preset return result for the call request when the call type is the second call type; the second call type is a request that does not require calling the graphics device to perform graphics tasks. The preset return result includes a preset success status; the preset success status is used to indicate that the call request corresponding to the second call type does not need to be converted into a call command and forwarded to the server.

[0119] Optional, selective processing module 402 includes: The command determination submodule is used to determine the command type corresponding to the request identifier based on a preset correspondence; the preset correspondence includes the correspondence between the request identifier and the command type.

[0120] The parameter item determination submodule is used to determine the parameter items required to execute the graphics task corresponding to the command type, based on the command type.

[0121] The command parameter determination submodule is used to extract the command parameters corresponding to the parameter items from the call parameters based on the parameter items.

[0122] The command generation submodule is used to generate invocation commands based on the command type and command parameters; the command type is used to characterize the graphics task that the server needs to execute, and the command parameters are used to characterize the data required to execute the graphics task.

[0123] Optionally, the user-space interception module 401 includes: The Device Identifier Acquisition Submodule is used to obtain the device identifier from the call request; the device identifier is used to identify the type of device to which the call request points.

[0124] The matching submodule is used to determine that the call request is a call request for a graphics device when the device identifier matches the preset graphics device identifier.

[0125] The intercept submodule is used to set up interception interfaces and intercept call requests through these interfaces.

[0126] Optional, selective processing module 402 includes: The processing category determination submodule matches the processing category corresponding to the request request in a preset call category table based on the request identifier; the preset call category table is used to record the correspondence between request identifiers and processing categories.

[0127] The call type determination submodule is used to determine the call type of the call request as the first call type when the processing category meets the preset first type condition; the preset first type condition includes: the processing category belongs to the category that needs to call the graphics device to perform graphics tasks.

[0128] Optionally, the graphics device invocation device further includes: The return module is used to obtain the task execution result sent by the server. The task execution result is the result obtained by the server calling the graphics device to execute the graphics task corresponding to the calling command according to the calling command.

[0129] Based on the aforementioned graphics device invocation device, the user equipment can intercept input / output control invocation requests through the user-mode interception module and determine the invocation type of the request based on the request identifier through the selective processing module. For invocation requests of the first invocation type, the user equipment can generate an invocation command and send it to the server through the execution module, causing the server to invoke the graphics device to execute the corresponding graphics task. For invocation requests of the second invocation type, the user equipment can directly generate a preset return result through the second processing module, avoiding invalid remote communication. Therefore, selective remote execution of graphics device invocation requests can be achieved without modifying the application's invocation method, reducing the user equipment's dependence on the local graphics device and improving the processing efficiency and compatibility of remote graphics device invocation.

[0130] This application provides a graphics device execution apparatus 50 applied to a server, such as... Figure 6 As shown, the graphics device execution device 50 includes: The request receiving module 501 is used to receive the call command sent by the user equipment; the call command is generated by the user equipment based on the call request from the graphics device.

[0131] The request execution module 502 is used to invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

[0132] The request feedback module 503 is used to obtain the execution results of the graphics task and send them to the user device.

[0133] Optionally, the request execution module 502 includes: The parsing submodule is used to parse the invoked command to obtain the command type and command parameters; the command type is used to characterize the graphics task corresponding to the invoked command, and the command parameters are used to characterize the data required to execute the graphics task.

[0134] The task determination submodule is used to match the graphical task corresponding to the command in the preset task mapping relationship based on the command type; the preset task mapping relationship is used to record the mapping relationship between command type and graphical task.

[0135] The task execution submodule is used to invoke the graphics device based on the graphics task and command parameters to execute the graphics task corresponding to the invoked command.

[0136] Based on the aforementioned graphics device execution mechanism, the server can receive invocation commands sent by the user device through the request receiving module, and invoke the graphics device to execute the corresponding graphics task according to the invocation command through the request execution module. Then, the request feedback module returns the execution result of the graphics task to the user device. Furthermore, the request execution module can parse the invocation command to obtain the command type and command parameters, determine the corresponding graphics task based on the command type, and then invoke the graphics device to execute the graphics task based on the command parameters. Thus, the server can accurately identify different invocation commands sent by the user device and invoke the graphics device to complete the corresponding processing, enabling graphics device invocation requests on the user device side to be transferred to the server side for execution. This reduces the user device's dependence on the local graphics device and improves the accuracy and stability of remote graphics device invocation.

[0137] Embodiments of this application also provide a graphics device computing system, such as... Figure 7 As shown, the interaction process, including user equipment and server, is as follows: After an application submits a call request via I / O control calls, the call request first enters the I / O control call router. This I / O control call router can be understood as a module used by the user-space interception module and selective processing module to determine the call type. The user equipment can obtain the request identifier from the call request through this router and determine the call type corresponding to the call request based on the request identifier.

[0138] In one example, the input / output control call router can determine the processing method for a call request based on an input / output control call processing function table. This processing function table can serve as an implementation of a preset call classification table and / or a preset mapping, used to record the correspondence between request identifiers and processing categories, and between request identifiers and command types. For example, when the request identifier corresponds to a buffer creation request or a task submission request, it can be determined that the call request belongs to the first call type, which requires calling the graphics device to execute a graphics task; when the request identifier corresponds to a context management request or a buffer list management request, it can be determined that the call request belongs to the second call type, which does not require calling the graphics device to execute a graphics task.

[0139] When the call request belongs to the first call type, it can enter the remote processing flow. Specifically, the protocol converter can generate a call command based on the request identifier and call parameters in the call request. The protocol converter can be understood as the module within the selective processing module responsible for generating call commands, used to convert the original call request into a call command that the server can recognize and process. Then, the user device can send the call command to the server through the execution engine interface for remote processing, enabling the server to invoke the graphics device to execute the corresponding graphics task based on the call command. For example, for a buffer creation request, a buffer creation class call command can be generated and sent to the server; for a task submission request, a task submission class call command can be generated and sent to the server.

[0140] When the call request belongs to the second call type, the call request can enter the local processing flow. Specifically, the user device may not generate a call command or send the call request to the server, but instead directly generate a preset return result for the call request. For example, for context management requests or buffer list management requests, the user device may generate a preset success status as a preset return result and return it to the application so that the application can continue the subsequent process.

[0141] Therefore, user equipment can selectively process input / output control call requests through the input / output control call router: for call requests that require the participation of the graphics device, the request is converted into a call command by a protocol converter and sent to the server via the execution engine interface; for call requests that do not require the graphics device to perform graphics tasks, a preset return result is generated on the user equipment side. This reduces unnecessary remote communication and server processing overhead, while ensuring the continuity of the original call flow of the application.

[0142] Based on the above scheme, the user equipment (UE) intercepts input / output control call requests through an interception interface, including call requests submitted directly through the direct rendering manager interface, thereby improving the completeness of call request interception. Furthermore, when the call type is the first type, the UE generates a call command based on the request identifier and call parameters, and sends the call command to the server. The server then calls the graphics device to execute the corresponding graphics task based on the call command. When the call type is the second type, the UE directly generates a preset return result, avoiding sending call requests that do not require the graphics device to execute graphics tasks to the server, thus reducing unnecessary remote communication and server processing overhead. Moreover, the call command can be processed by the same process logic in local mode for performance analysis, or sent to the server for execution in remote mode, thereby improving deployment flexibility. Since the call command represents the graphics task to be executed and its required data through command type and command parameters, it reduces the adaptation difficulty between different graphics device architectures and improves the scalability of the scheme. Meanwhile, the application still submits graphics device call requests in the original way, achieving remote graphics device calls without modifying application code or driver code, thereby improving the transparency and compatibility of the scheme.

[0143] The terms "first" and "second" in the specification and claims of this application may explicitly or implicitly include one or more of the features. In the description of this application, unless otherwise stated, "multiple" means two or more. Furthermore, "and / or" in the specification and claims indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0144] The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0145] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0146] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0147] The present invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for invoking a graphics device, characterized in that, Applied to user equipment, the method includes: Intercept the call request; the call request is a request submitted by the user equipment through input / output control call for invoking the graphics device; the call request includes a request identifier and call parameters; Based on the request identifier, determine the invocation type of the invocation request; When the call type is the first call type, a call command is generated based on the call parameters and the request identifier; the first call type is a request to call the graphics device to perform a graphics task; The invocation command is sent to the server so that the server can invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

2. The method according to claim 1, characterized in that, After determining the invocation type of the invocation request based on the request identifier, the method further includes: When the call type is the second call type, a preset return result of the call request is generated; the second call type is a request that does not require calling the graphics device to perform graphics tasks.

3. The method according to claim 1, characterized in that, The step of generating a call command based on the call parameters and the request identifier includes: The command type corresponding to the request identifier is determined according to a preset correspondence; the preset correspondence includes the correspondence between the request identifier and the command type. Based on the command type, determine the parameter items required to execute the graphics task corresponding to the command type; Based on the parameter item, extract the command parameter corresponding to the parameter item from the call parameters; The invocation command is generated based on the command type and the command parameters; the command type is used to characterize the graphics task that the server needs to execute, and the command parameters are used to characterize the data required to execute the graphics task.

4. The method according to claim 1, characterized in that, The intercepted call request includes: Obtain the device identifier from the call request; the device identifier is used to characterize the device type to which the call request points. When the device identifier matches a preset graphics device identifier, the call request is determined to be a call request for the graphics device. Set up an interception interface and intercept the call request through the interception interface.

5. The method according to claim 1, characterized in that, Determining the invocation type of the invocation request based on the request identifier includes: Based on the request identifier, the processing category corresponding to the call request is matched in a preset call classification table; the preset call classification table is used to record the correspondence between the request identifier and the processing category; When the processing category meets the preset first category condition, the call type of the call request is determined as the first call type; the preset first category condition includes: the processing category belongs to the category that needs to call the graphics device to perform graphics tasks.

6. The method according to claim 2, characterized in that, The preset return result includes a preset success status; The preset success status is used to indicate that the call request corresponding to the second call type does not need to be converted into the call command and forwarded to the server.

7. The method according to claim 1, characterized in that, After executing the graphics task corresponding to the invocation command, the method further includes: Obtain the task execution result sent by the server; the task execution result is the result obtained by the server after calling the graphics device according to the calling command to execute the graphics task corresponding to the calling command.

8. A method for executing graphics devices, characterized in that, Applied to the server side, the method includes: Receive a call command sent by a user equipment; the call command is generated by the user equipment based on the call request from the graphics device; The graphics device is invoked according to the invocation command to execute the graphics task corresponding to the invocation command; The execution result of the graphics task is obtained and sent to the user device.

9. The method according to claim 8, characterized in that, The step of invoking the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command includes: The invocation command is parsed to obtain the command type and command parameters; the command type is used to characterize the graphics task corresponding to the invocation command, and the command parameters are used to characterize the data required to execute the graphics task. Based on the command type, the graphical task corresponding to the calling command is matched in a preset task correspondence; the preset task correspondence is used to record the correspondence between the command type and the graphical task; Based on the graphics task and the command parameters, the graphics device is invoked to execute the graphics task corresponding to the invocation command.

10. A graphics device recall device, characterized in that, Applied to user equipment, the graphics device invocation device includes: The user-mode interception module is used to intercept call requests; the call request is a request submitted by the user device through input / output control to invoke the graphics device; the call request includes a request identifier and call parameters; A selective processing module is used to determine the invocation type of the invocation request based on the request identifier, and when the invocation type is a first invocation type, to generate an invocation command based on the invocation parameters and the request identifier; the first invocation type is a request that needs to invoke the graphics device to perform a graphics task; An execution module is used to send the invocation command to the server so that the server can invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command.

11. A graphics device execution apparatus, characterized in that, Applied to the server side, the graphics device execution device includes: A request receiving module is used to receive a call command sent by a user device; the call command is generated by the user device based on the call request from the graphics device. The request execution module is used to invoke the graphics device according to the invocation command to execute the graphics task corresponding to the invocation command; The request feedback module is used to obtain the execution result of the graphics task and send it to the user device.

12. A graphics device computing system, characterized in that, Including user equipment and server-side; The user equipment is used to execute the graphics device invocation method as described in any one of claims 1 to 7; The server is used to execute the graphics device execution method as described in any one of claims 8 to 9.

Images