A graphics rendering method, apparatus and electronic device

Abstract

The application provides a graphics rendering method, device and electronic equipment, wherein the graphics rendering method comprises: determining an instruction received by a first graphics processor installed on a first terminal and satisfying a preset condition as a target graphics rendering instruction; sending the target graphics rendering instruction to a second terminal; and receiving and displaying a target video frame generated by the second terminal based on the target graphics rendering instruction. By sending the target graphics rendering instruction to the second terminal, the first terminal can relieve the performance pressure of the graphics processor by virtue of the computing power advantage of the second terminal, and achieve efficient and smooth rendering of complex graphics.

Description

Technical Field

[0001] This application relates to the field of graphics rendering technology, and in particular to a graphics rendering method, apparatus and electronic device. Background Technology

[0002] With the development of automotive electronics technology, the demand for 3D interface displays such as 3D navigation and in-vehicle entertainment in in-vehicle scenarios is increasing. In existing technologies, complex graphics rendering tasks mostly rely on the vehicle's local graphics processor. However, due to limitations such as hardware cost and power consumption control, the computing power of the built-in graphics processor in the vehicle is generally insufficient. When running complex 3D graphics applications, problems such as stuttering, ghosting, and insufficient frame rate are prone to occur, which seriously affects the user experience. Summary of the Invention

[0003] This application provides a graphics rendering method, apparatus, and electronic device to solve the technical problem of rendering stuttering and delay caused by insufficient performance of the terminal's own graphics processor.

[0004] In a first aspect, embodiments of this application provide a graphics rendering method, applied to a first terminal, comprising: The instruction received by the first graphics processor that meets the preset conditions is determined as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal; Send the target graphics rendering command to the second terminal; Receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

[0005] Secondly, embodiments of this application provide a graphics rendering method applied to a second terminal, comprising: Receive the target graphics rendering command sent by the first terminal; Based on the target graphics rendering instructions, the rendering pipeline is reconstructed and graphics rendering is performed on the second graphics processor installed on the second terminal to obtain the target video frame. The target video frame is sent to the first terminal.

[0006] Thirdly, embodiments of this application also provide a graphics rendering apparatus, applied to a first terminal, the apparatus comprising: A determining module is used to determine the instruction received by the first graphics processor that meets preset conditions as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal; The first sending module is used to send the target graphics rendering instruction to the second terminal; The first receiving module is used to receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

[0007] Fourthly, embodiments of this application also provide a graphics rendering apparatus applied to a second terminal, the apparatus comprising: The second receiving module is used to receive the target graphics rendering command sent by the first terminal; The graphics rendering module is used to reconstruct the rendering pipeline and perform graphics rendering on the second graphics processor installed on the second terminal based on the target graphics rendering instructions to obtain the target video frame. The second sending module is used to send the target video frame to the first terminal.

[0008] Fifthly, embodiments of this application also provide an electronic device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described graphics rendering method.

[0009] Sixthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described graphics rendering method.

[0010] The embodiments of this application include at least the following technical effects: The technical solution of this application embodiment involves a first terminal sending a target graphics rendering instruction, which should be executed by itself, to a second terminal. The second graphics processor of the second terminal reconstructs the rendering pipeline based on the rendering context information carried by the instruction, and generates a target video frame after completing the graphics rendering. The first terminal receives and displays the target video frame generated by the second terminal. This leverages the computing power advantage of the second terminal to alleviate the performance pressure on the first terminal's own graphics processor, achieving efficient and smooth rendering of complex graphics. By fully capturing the rendering context and reconstructing the rendering pipeline, consistency of rendering effects across terminals can be guaranteed. This improves the user experience while effectively reducing related hardware upgrades and R&D costs, demonstrating strong practicality. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0012] Figure 1 This is one of the flowcharts illustrating the graphics rendering method provided in the embodiments of this application; Figure 2 This is a second schematic flowchart of the graphics rendering method provided in the embodiments of this application; Figure 3 This is one of the structural schematic diagrams of the graphics rendering apparatus provided in the embodiments of this application; Figure 4This is a second schematic diagram of the structure of the graphics rendering apparatus provided in the embodiments of this application; Figure 5 A block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0014] In related technologies, complex graphics rendering tasks often rely on the vehicle's local graphics processor. However, due to limitations such as hardware cost and power consumption control, the computing power of the built-in graphics processor in the vehicle is generally insufficient. When running complex 3D graphics applications, problems such as stuttering, ghosting, and insufficient frame rate are prone to occur, which seriously affects the user experience.

[0015] Based on this, this application provides a graphics rendering method, apparatus, and electronic device, which can alleviate the performance pressure on its own graphics processor by leveraging the computing power advantage of a second terminal, and achieve efficient and smooth rendering of complex graphics.

[0016] This application provides a graphics rendering method. Please refer to the following embodiments. Figure 1 Applied to the first terminal, it includes the following steps: Step 101: Determine the instruction received by the first graphics processor that meets the preset conditions as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal.

[0017] In this embodiment, the first terminal can be an in-vehicle infotainment system, and the second terminal can be a mobile phone. The performance of the second graphics processing unit (GPU) of the second terminal is superior to that of the first graphics processing unit of the first terminal.

[0018] When a target application installed on the first terminal needs to render complex graphics, it sends rendering-related instructions to the first GPU built into the vehicle's infotainment system (i.e., the first terminal) via a graphics API. In this embodiment, after the first GPU receives the instructions, it can identify those that meet preset conditions as target graphics rendering instructions. Alternatively, before these instructions reach the first GPU, it can call an interceptor via the rendering API to intercept them in real time, filtering out instructions that meet preset conditions and identifying them as target graphics rendering instructions. In this case, the intercepted target graphics rendering instructions will not be sent to the first GPU.

[0019] In this embodiment of the application, preset conditions are set when intercepting instructions to filter rendering instructions that need to be offloaded to the second terminal, thus avoiding invalid interception. These preset conditions include: the instruction type is a core graphics rendering instruction, such as drawing instructions like glDrawArrays and vkCmdDraw, and configuration instructions like shader switching and depth / blending state changes; the complexity of the rendering task corresponding to the instruction exceeds a threshold, such as a 3D model requiring rendering with more than 100,000 vertices and involving multi-layer lighting and shadow calculations; and the current GPU load of the vehicle's infotainment system exceeds a threshold, such as the GPU utilization rate reaching 80%, which would cause lag if continued execution were to proceed.

[0020] Specifically, the target applications are those installed on the first terminal that require 3D graphics rendering, such as in-vehicle 3D navigation applications, in-vehicle 3D game applications, and intelligent 3D interactive applications. The graphical interfaces that need to be rendered can be 3D city models, dynamic lighting effects, 3D virtual assistant images, etc.

[0021] It should be noted that the target graphics rendering instructions are a complete sequence of instructions and context information, including: drawing instructions, such as glDrawElements; configuration instructions, such as Shader program switching and depth state changes; resource association instructions, such as Uniform / DescriptorSet updates and texture binding; and render target configuration, such as RenderTarget switching. These instructions are combined in the order of execution and completely contain all the information required to render a complex graphic.

[0022] This application embodiment filters by preset conditions, only intercepting high-load rendering instructions, that is, only high-load instructions are identified as target graphics rendering instructions, avoiding invalid interception, ensuring the efficient execution of the vehicle system, i.e., the first terminal's local lightweight rendering task, and the second terminal renders the context through the target graphics rendering instructions, ensuring that the rendering environment can be completely replicated and guaranteeing rendering consistency.

[0023] Step 102: Send the target graphics rendering command to the second terminal.

[0024] After the first terminal determines the target graphics rendering instruction, it sends the target graphics rendering instruction to the second terminal through the communication channel. As an extended device, the second terminal can rebuild the rendering pipeline consistent with the vehicle's infotainment system (i.e., the first terminal) on its own second graphics processor after receiving the target graphics rendering instruction. Then, it maps the target graphics rendering instruction to the local interface instruction supported by the second GPU and executes the rendering to generate the target video frame.

[0025] To meet the low latency and high stability requirements of real-time rendering, communication channels typically use USB Direct or Wi-Fi Direct. During transmission, command data and associated texture and model resources are compressed to further reduce bandwidth usage.

[0026] Specifically, rebuilding the rendering pipeline on the second terminal is crucial for replicating the vehicle's rendering environment. It involves constructing a rendering pipeline object based on context information from the target graphics rendering instructions, determining the core rendering rules, restoring the shader and resource binding states, restoring the framebuffer / RenderPass configuration, parsing and loading the vertex / index buffer, and loading data such as the vertex coordinates and connection order of the 3D model into the second GPU to prepare for drawing. Since the second terminal's GPU may support different graphics APIs, the target graphics rendering instructions need to be mapped to native interface instructions. After mapping, the second GPU executes these native instructions on the reconstructed rendering pipeline, gradually generating consecutive video frames.

[0027] This application embodiment uses USB Direct / Wi-Fi Direct and data compression technology to ensure that command transmission is smooth and without packet loss, meeting the time requirements of real-time rendering; the rendering pipeline reconstructed by the second terminal is completely consistent with that of the vehicle-mounted system, i.e., the first terminal, ensuring that the rendering effect is identical.

[0028] Step 103: Receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

[0029] After rendering each frame based on the target graphics rendering instructions, the second terminal transmits the generated video frames back to the first terminal via the communication channel. Upon receiving the video stream, the first terminal decodes it in real time using its built-in decoder and displays the decoded image synchronously on the central control screen.

[0030] In this embodiment, a first terminal sends a target graphics rendering instruction, which should be executed by itself, to a second terminal. The second graphics processor of the second terminal can then reconstruct the rendering pipeline based on the rendering context information carried in the instruction, complete the graphics rendering, and generate a target video frame. The first terminal receives and displays the target video frame generated by the second terminal. By leveraging the computing power of the second terminal, the performance pressure on the first terminal's own graphics processor can be alleviated, achieving efficient and smooth rendering of complex graphics. By fully capturing the rendering context and reconstructing the rendering pipeline, the consistency of rendering effects across terminals can be guaranteed. This improves the user experience while effectively reducing related hardware upgrades and R&D costs, demonstrating strong practicality.

[0031] In an optional embodiment of this application, before determining the instruction received by the first graphics processor that meets preset conditions as the target graphics rendering instruction, the method further includes: Send a load request to the second terminal; Receive the load of the second graphics processor detected by the second terminal based on the load request; determine whether the load is less than a preset load threshold; When the load is less than the preset load threshold, the step of determining the instruction received by the first graphics processor that meets the preset conditions as the target graphics rendering instruction is executed.

[0032] Before performing cross-terminal distributed rendering, this application embodiment detects whether the second graphics processor of the second terminal has sufficient idle computing power to ensure that the second terminal can complete the rendering task unloaded by the first terminal.

[0033] Specifically, before determining the instruction received by the first graphics processor installed on the first terminal that meets preset conditions as the target graphics rendering instruction, a load request is sent to the second terminal. The second terminal responds to the load request, collects the current load data of its own second graphics processor in real time, and feeds it back to the first terminal. The load reflects the activity level of the second graphics processor, including the GPU resource utilization rate, the number of currently running rendering tasks, and the remaining computing power. For example, it detects whether the second GPU of the second terminal is running high-performance applications such as large 3D games or 4K video editing at full capacity. These applications consume a large amount of GPU computing power, making it difficult for the second terminal to handle new rendering tasks.

[0034] Furthermore, after receiving the GPU load data from the second terminal, the first terminal compares the actual load with a pre-set load threshold to determine whether the second terminal's GPU has sufficient idle computing power to handle the rendering tasks from the first terminal. The pre-set load threshold is a reasonable critical value set based on the rendering task requirements and the performance of the second terminal's GPU, balancing computing power utilization and rendering stability. It typically considers factors such as the peak performance of the second terminal's GPU and the computing power requirements of the in-vehicle scene rendering task. If the actual load of the second terminal's GPU is lower than this threshold, it indicates that it has sufficient idle computing power; if it is equal to or higher than this threshold, it indicates that its current computing power is saturated or nearly saturated and cannot handle new rendering tasks.

[0035] When the judgment result indicates that the GPU load of the second terminal is less than the preset load threshold, it means that the second terminal has the ability to handle rendering tasks. At this time, the first terminal starts the rendering API call interceptor and begins to intercept rendering instructions sent by the target application to the first graphics processor that meet the preset conditions in real time, so as to determine the target graphics rendering instructions. If the load does not meet the conditions, the step of determining the target graphics rendering instructions is not executed, and the first graphics processor processes the rendering instructions.

[0036] The above-described implementation scheme of this application, before determining the target graphics rendering instruction, first detects the load of the second graphics processor on the second terminal and compares it with a preset load threshold. Subsequent processes are only initiated when the load meets the condition, avoiding offloading rendering tasks to the second terminal with insufficient computing power, thus ensuring the stability and smoothness of distributed rendering. Local rendering is retained when the second terminal is under high load, ensuring the normal operation of the application. This optimizes the efficiency of computing resource scheduling and eliminates the need to upgrade the hardware of the first terminal, effectively controlling costs while improving user experience.

[0037] In an optional embodiment of this application, sending the target graphics rendering instruction to the second terminal includes: The target graphics rendering instruction is serialized, and the resource information carried by the target graphics rendering instruction is compressed to obtain target data; The target data is sent to the second terminal.

[0038] After the first terminal determines the target graphics rendering instructions, it does not directly transmit the original instructions. Instead, it first performs serialization conversion on the instructions, transforming the non-standardized rendering instructions originally bound to the first graphics processor, such as OpenGL / Vulkan API call sequences, into cross-device common data formats like JSON / Protobuf. Simultaneously, it uses a dedicated compression algorithm to compress the resource information such as textures and models carried in the instructions, reducing storage space and transmission bandwidth. Finally, it integrates the serialized instructions with the compressed resource information to obtain the target data.

[0039] Specifically, the serialized object is a complete sequence of target graphics rendering instructions, including all rendering-related instructions such as drawing calls, shader program switching, depth / blending state changes, and Uniform parameter updates, as well as information such as the execution order of instructions and rendering context relationships. For example, the instruction sequence for "drawing a 3D model of a highway bridge" in a 3D navigation application includes steps such as "loading bridge vertex data," "binding bridge surface textures," "starting depth testing," and "executing drawing calls." Serialization processes convert these instructions into a universal format in sequence, ensuring that the second terminal can accurately parse the instruction logic. This eliminates device dependency of instructions, allowing terminals with different hardware and APIs to recognize the meaning of the instructions. Resource information refers to the material data required for rendering, mainly including texture resources and 3D model resources. The original data volume of these resources is large, and direct transmission would severely impact efficiency. Lossless or near-lossless compression algorithms can be used to reduce data volume without affecting the final rendering effect. The target data is an integration of serialized instructions and compressed resources, including an instruction layer and a resource layer. The instruction layer records the complete rendering instruction sequence and context information, while the resource layer stores compressed texture and model data. The two layers of data are associated through identifiers to ensure that the second terminal can accurately match the instructions with the corresponding resources during parsing.

[0040] After the first terminal completes the serialization and compression processing, it transmits the entire target data to the second terminal in real time through the communication channel.

[0041] Specifically, a checksum can be added to the target data during transmission. After receiving the data, the second terminal verifies its integrity using the checksum. For example, when the vehicle's infotainment system sends target data, it calculates the CRC checksum of the data and sends it along with the data. The mobile phone receives the data and recalculates the checksum. If it matches the sender's checksum, the data is considered complete; otherwise, a retransmission is requested to avoid data corruption due to transmission interference.

[0042] For example, when a user uses 3D navigation on the vehicle's infotainment system, the system integrates the serialized 3D city model rendering instructions with the compressed city building textures and road models into target data, which is then transmitted to the mobile phone in real time via a USB direct connection channel.

[0043] In the above-described implementation scheme of this application, when sending the target graphics rendering command to the second terminal, the command is first serialized, and the resource information it carries is compressed to obtain the target data before the target data is transmitted to the second terminal. Serialization eliminates device dependency of the command, achieving cross-device compatibility and allowing the second terminal to accurately parse the command logic and rendering context. Resource compression reduces data size and bandwidth usage, ensuring efficient, complete, and timely data transmission, providing a foundation for the second terminal to reconstruct the rendering pipeline and restore consistent rendering effects.

[0044] In an optional embodiment of this application, the instruction received by the first graphics processor that meets preset conditions is determined as the target graphics rendering instruction, including: Determine the set of preset rendering interfaces; The instructions sent to the first graphics processor through any of the preset rendering interface sets are intercepted to obtain the target graphics rendering instructions.

[0045] This application embodiment predefines a set of interfaces strongly related to graphics rendering, limiting the interception scope to interface calls within this set, avoiding invalid interception of non-rendering instructions, and ensuring that the intercepted target graphics rendering instructions are complete and without redundancy.

[0046] Specifically, the first terminal pre-constructs a set of preset rendering interfaces. This set includes all core API interfaces directly related to graphics rendering and serves as the basis for filtering subsequent instruction interception. The determination of the set must be based on the graphics APIs used by the target application and cover all key interfaces in the rendering process to ensure that no core instruction interfaces affecting the rendering effect are missed. The preset rendering interface set includes three types of interfaces: drawing interfaces (such as OpenGL's glDrawArrays and Vulkan's vkCmdDraw), responsible for triggering GPU drawing actions; configuration interfaces (such as Shader program switching interfaces and depth / blending state change interfaces), responsible for defining rendering rules; and resource binding interfaces (such as Uniform parameter update interfaces and texture binding interfaces), responsible for associating the materials and parameters required for rendering. For example, for the OpenGL API used by a 3D navigation application, the preset rendering interface set includes at least the glDrawElements (drawing call), glUseProgram (shader switching), glUniform1f (parameter update), and glBindTexture (texture binding) interfaces.

[0047] After the first terminal initiates the rendering API call interceptor, the interceptor will monitor all interface calls sent by the target application to the first graphics processor in real time. Only when the called interface belongs to a preset rendering interface set will the interceptor intercept the corresponding instructions and organize them into a complete instruction sequence according to the order in which the instructions were sent, ultimately forming the target graphics rendering instructions. For interface calls that do not belong to this set, such as the application's file operation interface or user interaction response interface, the interceptor will not perform any processing.

[0048] For example, after the in-vehicle 3D game application starts, it will call interfaces in a preset set such as vkCreateGraphicsPipelines (create rendering pipeline), vkCmdBindPipeline (bind pipeline), and vkCmdDraw (draw game character). The interceptor will intercept these instructions and form the target graphics rendering instructions. However, when the game application calls the interface for processing user key input, it will not be intercepted because it is not in the preset set, ensuring that user interaction instructions are transmitted normally.

[0049] The above-described implementation scheme of this application, by pre-determining a set of preset rendering interfaces, intercepts only the instructions sent to the first graphics processor through any one of the interfaces in the set, thereby obtaining the target graphics rendering instructions. This clarifies the interception scope, limits the interception target to interfaces strongly related to graphics rendering, avoids invalid interception of non-rendering instructions, reduces the system resource consumption of the first terminal, and improves the interception efficiency.

[0050] In an optional embodiment of this application, before sending the target graphics rendering instruction to the second terminal, the method further includes: Determine whether a communication channel for rendering task migration has been established between the first terminal and the second terminal; When the communication channel is available, the target graphics rendering command is sent to the second terminal through the communication channel; When the communication channel is not available, a rendering task migration request carrying a preset service is sent to the second terminal; wherein, in response to the rendering task migration request, the second terminal installs the preset service, establishes the communication channel, and sends rendering task migration confirmation information back to the first terminal. Upon receiving the rendering task migration confirmation information sent by the second terminal, the target graphics rendering instruction is sent to the second terminal through the communication channel.

[0051] Before sending the target graphics rendering command, the first terminal in this application embodiment verifies the availability of the existing channel to avoid command transmission failure. If the channel is not established, the second terminal is triggered to install the necessary components and complete the channel construction through the automatic deployment and configuration of the preset service, so as to finally achieve reliable transmission of the command.

[0052] Specifically, before sending the target graphics rendering instructions to the second terminal, it is determined whether a communication channel for rendering task migration has been established between the first and second terminals. This ensures that the channel is not only physically connected but also that the protocol, permissions, and services are ready to carry subsequent instructions and video stream transmission. The communication channel for rendering task migration is not an ordinary network connection but a link with specific requirements. Protocol adaptation: Supports low-latency, high-throughput transmission protocols, such as high-speed data transmission protocols based on USB or optimized Wi-Fi Direct protocols. Service binding: Both ends of the channel need to run corresponding rendering task migration services, responsible for sending, receiving, parsing, and synchronizing instructions. Permission verification: Ensures that both communicating parties are trusted devices to prevent data leakage or malicious attacks.

[0053] When a communication channel is available, it indicates that a usable, dedicated communication channel already exists between the first terminal and the second terminal. At this time, the first terminal does not need to perform any additional operations; it can directly send the serialized and compressed target graphics rendering instructions to the second terminal through this readily available channel.

[0054] For example, when a user is driving a vehicle, the phone and the vehicle's infotainment system are connected via USB and a dedicated channel has been established. When the user opens a 3D navigation application on the vehicle's infotainment system, the system detects that the channel exists, immediately intercepts and sends rendering commands, and the phone quickly begins rendering. The entire process is seamless, and the user experiences virtually no delay.

[0055] When no communication channel exists, the first terminal will proactively initiate a channel establishment process. First, it sends a rendering task migration request to the second terminal, carrying with it the installation package or download link for the preset services necessary for the second terminal to establish the channel. The preset service is a lightweight application or background process that can be installed on the second terminal, acting as a client for cross-terminal rendering. Its functions include: channel management (negotiating, establishing, and maintaining a dedicated communication channel with the first terminal); instruction processing (receiving and parsing serialized rendering instructions from the first terminal); rendering execution (calling the second terminal's GPU to execute rendering tasks); and video transmission (encoding the rendered video frames and sending them back to the first terminal).

[0056] For example, when a user pairs their phone with the car's infotainment system for the first time, the system detects the lack of a dedicated channel and sends a QR code containing a download link for a preset service to the phone via Bluetooth. The user can then scan the QR code on their phone to automatically download and install the in-vehicle rendering assistant, which is the preset service.

[0057] After receiving the rendering task migration request from the first terminal, the second terminal will automatically initiate the installation process of the preset service. Once installed, the service will run automatically in the background and, based on the information in the request, negotiate protocols and exchange keys with the first terminal, ultimately establishing an encrypted, dedicated communication channel. After the channel is successfully established, the second terminal sends a rendering task migration confirmation message to the first terminal.

[0058] After receiving confirmation from the second terminal, the first terminal will send the previously prepared, serialized, and compressed target graphics rendering instructions to the second terminal through this newly established dedicated channel, and the subsequent rendering process can then begin.

[0059] In the above-described implementation scheme of this application, before sending the target graphics rendering command, it first determines whether a rendering task migration communication channel has been established between the first terminal and the second terminal. If it has been established, the transmission is performed directly. If not, a migration request carrying a preset service is sent to the second terminal. The transmission is performed only after the second terminal installs the service, establishes the channel, and sends back confirmation information. This ensures a stable and reliable communication link and avoids command transmission failure. The preset service is automatically deployed to complete the channel setup during the first connection. The existing channel is reused to achieve rapid startup, which greatly improves ease of use and user experience.

[0060] This application provides a graphics rendering method. Please refer to the following embodiments. Figure 2 When applied to a second terminal, the procedure includes the following steps: Step 201: Receive the target graphics rendering command sent by the first terminal.

[0061] The second terminal receives the target graphics rendering instructions sent by the first terminal in real time through a pre-established communication channel (such as USB Direct or Wi-Fi Direct).

[0062] Specifically, the target graphics rendering instructions received by the second terminal are integrated data after being serialized (e.g., converted to JSON / Protobuf format) and compressed by the first terminal. After receiving the data, the integrity of the data must be verified by a checksum (e.g., CRC check) to avoid instruction loss due to transmission interference. Then, a dedicated parsing module converts the serialized instructions in the general format into a rendering instruction structure that it can recognize, while decompressing the associated texture, model and other resource information.

[0063] For example, when a user activates 3D augmented reality navigation on the vehicle's infotainment system, the system intercepts rendering commands sent to its GPU by the navigation application, serializes and compresses them, and then transmits them to the mobile phone, the second terminal. The mobile phone receives the command data via USB, first verifies the data integrity, and then parses out the specific rendering commands and associated resource information, such as "drawing the highway bridge," "binding the bridge surface texture," and "setting lighting parameters."

[0064] Step 202: Based on the target graphics rendering instructions, the rendering pipeline is reconstructed and graphics rendering is performed on the second graphics processor installed on the second terminal to obtain the target video frame.

[0065] The second terminal, based on the target graphics rendering instructions, reconstructs a rendering pipeline identical to that of the first terminal on the second graphics processor. Simultaneously, it maps the target graphics rendering instructions to native interface instructions supported by the second graphics processor. Rendering actions are then executed on the reconstructed rendering pipeline, gradually generating consecutive target video frames. The entire process must strictly adhere to the execution order of the instruction sequence to ensure that the rendering logic is completely consistent with the vehicle's infotainment system.

[0066] Specifically, the rendering pipeline reconstruction process is based on the rendering context information in the target graphics rendering instructions, including: constructing a rendering pipeline object (PSO) to determine the core rendering rules; restoring the shader and resource binding state, binding the shader program specified by the instructions, loading the decompressed textures, models, and other resources, and associating them with the corresponding rendering stages; restoring the Framebuffer / RenderPass configuration to determine the virtual canvas size and rendering stage division; and loading the vertex / index buffer, loading the vertex coordinates, connection order, and other data of the 3D model into the second graphics processor. After the rendering pipeline reconstruction is completed, the second terminal maps the parsed target graphics rendering instructions to the local interface instructions supported by its own second graphics processor. The mapping must ensure functional equivalence to ensure that the rendering effect is consistent with the vehicle's infotainment system. Subsequently, these local instructions are executed on the reconstructed rendering pipeline to complete actions such as graphics drawing and parameter updates in sequence, generating a single frame of rendering. By continuously executing multiple sets of instructions, continuous target video frames can be obtained.

[0067] Step 203: Send the target video frame to the first terminal.

[0068] After the second terminal completes the rendering of a single frame, it transmits the video frame back to the first terminal in real time through the communication channel established with the first terminal. A frame synchronization mechanism can be used during transmission to ensure that the transmission order of the video frames is consistent with the rendering order.

[0069] Specifically, the raw rendered video data is extremely large, and direct transmission would consume a lot of bandwidth and cause latency. Hardware encoding can significantly compress the data size while preserving image quality. For example, after a mobile phone generates 3D navigation video frames, it encodes them into H.265 format using the hardware encoder integrated into its GPU.

[0070] In this embodiment, the second terminal receives target graphics rendering instructions sent by the first terminal, reconstructs a rendering pipeline consistent with that of the first terminal on the second graphics processor based on the instructions, completes graphics rendering, and then sends the target video frame back to the first terminal. This leverages the computing power of the second terminal to handle complex rendering tasks that are difficult for the first terminal's graphics processor to handle, thus resolving the rendering lag issue in in-vehicle systems. By accurately parsing instructions and reconstructing the rendering pipeline, consistency in rendering effects across terminals is ensured, avoiding visual anomalies.

[0071] In an optional embodiment of this application, receiving a target graphics rendering instruction sent by a first terminal includes: Receive target data sent by the first terminal; The target data is deserialized and the resource information is decompressed to obtain the target graphics rendering instructions.

[0072] When the second terminal receives the target graphics rendering command sent by the first terminal, it receives the target data transmitted by the first terminal in real time through a dedicated communication channel (such as USB Direct or Wi-Fi Direct) pre-established with the first terminal. This target data is integrated data that has undergone serialization and resource compression to adapt to the efficiency and compatibility of cross-terminal transmission.

[0073] After receiving the target data, the second terminal needs to perform two operations: first, deserialization, which restores the general format instruction sequence converted by the first terminal into the original rendering instruction structure that the second terminal can recognize, while preserving the execution order and contextual relationships of the instructions; second, resource information decompression, which uses the reverse algorithm corresponding to the compression algorithm of the first terminal to restore the simplified texture, model and other resource information to their original size and precision, and finally integrates them to obtain complete and executable target graphics rendering instructions.

[0074] For example, after the mobile phone receives the 3D surround-view parking target data transmitted by the vehicle's system, it first performs deserialization processing to restore the general format instructions to specific instructions such as drawing the vehicle outline, binding the parking guide line texture, and setting the semi-transparent blending mode; then, through a decompression algorithm, it restores the compressed vehicle model and guide line texture to their original size and precision, and finally obtains the target graphics rendering instructions that are consistent with the original instructions from the vehicle's system.

[0075] In the above implementation scheme of this application, the second terminal receives the target data sent by the first terminal, and obtains the target graphics rendering instructions through deserialization and resource decompression and restoration. Deserialization realizes cross-terminal adaptation of instruction format and solves the instruction compatibility problem caused by software and hardware differences; resource decompression restores the complete rendering resources and provides support for subsequent rendering pipeline reconstruction.

[0076] In an optional embodiment of this application, the target video frame is obtained by reconstructing the rendering pipeline and performing graphics rendering on a second graphics processor based on the target graphics rendering instructions, including: The target graphics rendering instructions are mapped to native interface instructions supported by the second graphics processor; Based on the rendering context information carried by the target graphics rendering instruction, the rendering pipeline is reconstructed on the second graphics processor; Based on the rendering pipeline, the local interface instructions are executed to obtain the target video frame.

[0077] Since the graphics processors (GPUs) of the first and second terminals may support different graphics APIs, cross-API instruction conversion is required through mapping. For example, the first GPU of the first terminal (vehicle infotainment system) supports the OpenGL API, and the transmitted target graphics rendering instructions are OpenGL-formatted 3D building rendering instructions; while the second GPU of the second terminal (mobile phone) supports the Vulkan API. In this case, the OpenGL-formatted rendering instructions need to be mapped to the corresponding Vulkan native interface instructions to ensure that the second GPU can accurately recognize and execute them. Therefore, after the second terminal receives and restores the target graphics rendering instructions, it first performs an instruction adaptation operation. Through a dedicated instruction mapping module, the core functions of the target graphics rendering instructions are analyzed and converted into native interface instructions compatible with the second GPU. The mapping process must ensure complete functional equivalence, without changing the original rendering logic and parameter configuration, only completing the adaptation and conversion of instruction format and interface type. The mapped native interface instructions are completely consistent with the original target graphics rendering instructions in function, including rendering action type, parameter configuration, execution order, etc.

[0078] For example, the mobile phone receives 3D navigation target graphics rendering instructions transmitted from the vehicle's infotainment system, which include OpenGL format instructions such as "glDrawArrays (draw road model)" and "glUniform1f (set lighting intensity)". The mobile phone's instruction mapping module maps these instructions to Vulkan format native interface instructions such as "vkCmdDraw" and "vkUpdateDescriptorSets", strictly preserving core information such as the road model's drawing parameters and lighting intensity values ​​during the mapping process.

[0079] Furthermore, based on the rendering context information carried by the target graphics rendering instructions, a rendering pipeline completely identical to that of the first terminal is constructed on the second graphics processor. The reconstruction process needs to cover the configuration of the entire rendering pipeline, including rendering rule definition, shader program binding, resource association, rendering target settings, etc., ultimately forming a rendering environment to ensure that subsequent execution of rendering instructions can follow the same rendering logic as the first terminal.

[0080] Specifically, rendering context information is the core basis for replicating the rendering environment, including: rendering pipeline configuration parameters (such as depth test enabled status, semi-transparent blending mode, anti-aliasing settings, etc.); shader program information (such as the code logic and parameter configuration of vertex shaders and fragment shaders); resource binding relationships (such as the association between textures, 3D model data and the rendering stage); and rendering target information (such as the resolution and pixel format of the rendered image, etc.).

[0081] During rendering pipeline reconstruction, the process proceeds in the order of "rule definition - resource binding - state configuration": A rendering pipeline object (PSO) is constructed, defining the core rules of rendering, such as the processes for vertex processing, rasterization, pixel shading, and depth testing, and clarifying the processing standards for each stage; Shader programs are bound, loading the shader programs specified in the rendering context information into the second graphics processor and configuring the corresponding parameters; rendering resources are associated, linking decompressed textures, 3D models, and other resources to the corresponding stages of the rendering pipeline according to the binding relationships defined in the context; and rendering targets are set, configuring the rendering resolution, pixel format, etc., to be consistent with the first terminal.

[0082] Finally, after the rendering pipeline is rebuilt, the second terminal generates and executes local interface instructions one by one on the rebuilt rendering pipeline according to the original execution order of the target graphics rendering instructions. Through continuous instruction execution, the second graphics processor processes resources such as textures and models according to the rules defined by the rendering pipeline, gradually generating single-frame rendering images; multiple consecutive rendering images are combined in sequence to form a smooth target video frame sequence, completing the graphics rendering task.

[0083] It should be noted that the order of the original target graphics rendering instructions must be followed during execution to ensure the continuity of the rendering logic.

[0084] The above-described implementation scheme of this application maps the target graphics rendering instructions to native interface instructions supported by the second graphics processor, reconstructs the rendering pipeline based on the rendering context information carried by the instructions, and then executes the native interface instructions based on the pipeline to obtain the target video frame. Instruction mapping solves the instruction compatibility problem caused by differences in graphics APIs across terminals, ensuring the consistency of rendering logic; pipeline reconstruction realizes the replication of the rendering environment consistent with the first terminal, providing a foundation for accurate rendering.

[0085] The overall implementation process of the embodiments of this application is described below, including the following steps: Step 1: Establish a communication channel between devices: Establish a communication channel between the vehicle's infotainment system and the extended devices via methods such as USB Direct or Wi-Fi Direct. The establishment of this communication channel must ensure low latency and high stability to meet real-time rendering requirements.

[0086] Step 2: Abstracting and Serializing Rendering Instructions: Intercept OpenGL / Vulkan API calls from the map application on the vehicle's infotainment system and serialize the rendering instructions (such as draw calls and shader parameters) into formats like JSON / Protobuf. Simultaneously, compress resources such as textures and models to reduce the amount of data transmitted. The serialization of rendering instructions must ensure the integrity and accuracy of the instructions while reducing data volume to improve transmission efficiency. Texture and model compression needs to balance compression ratio and rendering quality.

[0087] Unlike conventional data serialization, the objects serialized in this application originate from rendering API call interceptors, including but not limited to: glDrawArrays / glDrawElements; vkCmdDraw / vkCmdBindPipeline; Shader program switching; Uniform / DescriptorSet update; RenderTarget switching; Depth / Blending / Raster State Change.

[0088] The aforementioned GPU instructions and rendering states constitute a complete sequence of rendering instructions, which can reconstruct the original rendering context on the extended device.

[0089] Step 3: Dynamically Reconstruct the Rendering Pipeline on the Extended Device Side: After receiving data, the extended device (such as a smartphone) decompresses the resources and parses the serialization instructions. Then, it maps the instructions to local API calls supported by the extended device's GPU and invokes the GPU to execute rendering and generate video frames. The extended device must possess powerful computing capabilities and GPU support to ensure the smooth execution of the rendering task.

[0090] After parsing the rendering instructions, the extended device will automatically: Construct a rendering pipeline state object (PSO); Restore the corresponding shader, material, and texture binding state; Restore Framebuffer / RenderPass configuration; Parse and load the vertex / index buffer; Execute the same draw call as on the vehicle's infotainment system.

[0091] Ensure that the rendering results from the remote end are consistent with the native rendering effect of the vehicle system, and achieve GPU-level cross-device rendering consistency reconstruction.

[0092] Step 4, Image Transmission and Vehicle Display: The extended device transmits the rendered video frames back to the vehicle's infotainment system via the communication channel. The vehicle's infotainment system then decodes and displays the video frames.

[0093] The aforementioned implementation scheme proposes a cross-device distributed execution framework at the rendering API level. This framework migrates the rendering pipeline, originally bound to the vehicle's GPU, to an extended device GPU and completely reconstructs it, rather than relying on traditional data transmission or UI-level data visualization. It achieves fine-grained abstraction at the rendering instruction level, fully replicating the original rendering context, including the rendering state machine, shader pipeline, and resource binding relationships—content that traditional JSON data serialization struggles to cover. This application constructs a closed-loop architecture encompassing rendering instructions, cross-device transmission, rendering pipeline reconstruction, GPU rendering, and video backhaul, enabling remote offloading of vehicle-mounted GPU rendering tasks.

[0094] This application also provides a graphics rendering device for a first terminal. Please refer to [link / reference]. Figure 3 The graphics rendering device 30 includes: The determining module 310 is used to determine the instruction received by the first graphics processor that meets the preset conditions as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal; The first sending module 320 is used to send the target graphics rendering instruction to the second terminal; The first receiving module 330 is used to receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

[0095] Optionally, before determining the instruction received by the first graphics processor that meets preset conditions as the target graphics rendering instruction, the apparatus further includes: The third sending module is used to send a load request to the second terminal; The third receiving module is used to receive the load of the second graphics processor detected by the second terminal based on the load request; The first judgment module is used to determine whether the load is less than a preset load threshold; when the load is less than the preset load threshold, the module executes the step of sending the target graphics rendering instruction to the second terminal.

[0096] Optionally, the first transmitting module includes: The first processing submodule is used to serialize the target graphics rendering instruction and compress the resource information carried by the target graphics rendering instruction to obtain target data. The sending submodule is used to send the target data to the second terminal.

[0097] Optionally, the determination module includes: The submodule is used to determine the set of preset rendering interfaces; The interception submodule is used to intercept instructions sent to the first graphics processor through any of the preset rendering interface sets to obtain the target graphics rendering instructions.

[0098] Optionally, before sending the target graphics rendering command to the second terminal, the device further includes: The second judgment module is used to determine whether a communication channel for rendering task migration has been established between the first terminal and the second terminal; when the communication channel exists, the target graphics rendering instruction is sent to the second terminal through the communication channel. The fourth sending module is used to send a rendering task migration request carrying a preset service to the second terminal when there is no communication channel; wherein, in response to the rendering task migration request, the second terminal installs the preset service, establishes the communication channel, and sends rendering task migration confirmation information back to the first terminal; upon receiving the rendering task migration confirmation information sent by the second terminal, the module sends the target graphics rendering instruction to the second terminal through the communication channel.

[0099] The graphics rendering apparatus provided in this application achieves the following technical effects: A first terminal sends a target graphics rendering instruction, which should be executed by itself, to a second terminal. The second graphics processor of the second terminal can then reconstruct the rendering pipeline based on the rendering context information carried by the instruction, and generate a target video frame after completing the graphics rendering. The first terminal receives and displays the target video frame generated by the second terminal. This leverages the computing power of the second terminal to alleviate the performance pressure on the first terminal's own graphics processor, achieving efficient and smooth rendering of complex graphics. By fully capturing the rendering context and reconstructing the rendering pipeline, consistency in rendering effects across terminals can be guaranteed. This improves the user experience while effectively reducing related hardware upgrades and R&D costs, demonstrating strong practicality.

[0100] This application also provides a graphics rendering device for a second terminal. Please refer to [link / reference]. Figure 4 The graphics rendering device 40 includes: The second receiving module 410 is used to receive the target graphics rendering instruction sent by the first terminal; The graphics rendering module 420 is used to reconstruct the rendering pipeline and perform graphics rendering on the second graphics processor installed on the second terminal based on the target graphics rendering instruction to obtain the target video frame. The second sending module 430 is used to send the target video frame to the first terminal.

[0101] Optionally, the second receiving module includes: The receiving submodule is used to receive the target data sent by the first terminal; The second processing submodule is used to deserialize the target data and decompress the resource information to obtain the target graphics rendering instructions.

[0102] Optionally, the graphics rendering module includes: A mapping submodule is used to map the target graphics rendering instructions to native interface instructions supported by the second graphics processor; The reconstruction submodule is used to reconstruct the rendering pipeline on the second graphics processor based on the rendering context information carried by the target graphics rendering instruction. The execution submodule is used to execute the local interface instructions based on the rendering pipeline to obtain the target video frame.

[0103] The graphics rendering apparatus provided in this application embodiment achieves the following technical effects: The second terminal receives the target graphics rendering command intercepted by the first terminal, reconstructs a rendering pipeline consistent with that of the first terminal on the second graphics processor based on the command, completes graphics rendering, and then sends the target video frame back to the first terminal. This leverages the computing power advantage of the second terminal to handle complex rendering tasks that are difficult for the first terminal's first graphics processor to handle, thus solving the problem of rendering lag in in-vehicle systems. By accurately parsing the command and reconstructing the rendering pipeline, consistency in rendering effects across terminals is ensured, avoiding image anomalies.

[0104] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0105] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0106] This application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described graphics rendering method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0107] For example, Figure 5 A schematic diagram of the physical structure of an electronic device is shown. (For example...) Figure 5As shown, the electronic device 50 may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530. The processor 510 is used to perform the following steps: determining an instruction that meets preset conditions received by the first graphics processor installed on the first terminal as a target graphics rendering instruction; sending the target graphics rendering instruction to the second terminal; receiving and displaying a target video frame generated by the second terminal based on the target graphics rendering instruction. The processor 510 is also used to perform the following steps: receiving the target graphics rendering instruction sent by the first terminal; reconstructing the rendering pipeline and performing graphics rendering on the second graphics processor installed on the second terminal based on the target graphics rendering instruction to obtain a target video frame; and sending the target video frame to the first terminal. The processor 510 can also execute other schemes in the embodiments of this application, which will not be further described here.

[0108] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0109] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described graphics rendering method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0110] In this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0111] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0112] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] In this application, "multiple" refers to two or more.

[0114] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0115] The terms “first,” “second,” “third,” “fourth,” etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0116] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0117] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0118] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A graphics rendering method, applied to a first terminal, characterized in that, include: The instruction received by the first graphics processor that meets the preset conditions is determined as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal; Send the target graphics rendering command to the second terminal; Receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

2. The graphics rendering method according to claim 1, characterized in that, Before determining the instruction received by the first graphics processor that meets the preset conditions as the target graphics rendering instruction, the method further includes: Send a load request to the second terminal; The second terminal receives the load of the second graphics processor detected based on the load request; wherein the second graphics processor is installed in the second terminal; Determine whether the load is less than a preset load threshold; When the load is less than the preset load threshold, the step of determining the instruction received by the first graphics processor that meets the preset conditions as the target graphics rendering instruction is executed.

3. The graphics rendering method according to claim 1, characterized in that, Sending the target graphics rendering command to the second terminal includes: The target graphics rendering instruction is serialized, and the resource information carried by the target graphics rendering instruction is compressed to obtain target data; The target data is sent to the second terminal.

4. The graphics rendering method according to claim 1, characterized in that, The instructions received by the first graphics processor that meet preset conditions are identified as target graphics rendering instructions, including: Determine the set of preset rendering interfaces; The instructions sent to the first graphics processor through any of the preset rendering interface sets are intercepted to obtain the target graphics rendering instructions.

5. The graphics rendering method according to claim 1, characterized in that, Before sending the target graphics rendering command to the second terminal, the method further includes: Determine whether a communication channel for rendering task migration has been established between the first terminal and the second terminal; When the communication channel is available, the target graphics rendering command is sent to the second terminal through the communication channel; When the communication channel is not available, a rendering task migration request carrying a preset service is sent to the second terminal; wherein, in response to the rendering task migration request, the second terminal installs the preset service, establishes the communication channel, and sends rendering task migration confirmation information back to the first terminal. Upon receiving the rendering task migration confirmation information sent by the second terminal, the target graphics rendering instruction is sent to the second terminal through the communication channel.

6. A graphics rendering method, applied to a second terminal, characterized in that, include: Receive the target graphics rendering command sent by the first terminal; Based on the target graphics rendering instructions, the rendering pipeline is reconstructed and graphics rendering is performed on the second graphics processor installed on the second terminal to obtain the target video frame. The target video frame is sent to the first terminal.

7. The graphics rendering method according to claim 6, characterized in that, Receive the target graphics rendering command sent by the first terminal, including: Receive target data sent by the first terminal; The target data is deserialized and the resource information is decompressed to obtain the target graphics rendering instructions.

8. The graphics rendering method according to claim 6, characterized in that, Based on the target graphics rendering instructions, the rendering pipeline is reconstructed and graphics rendering is performed on the second graphics processor to obtain the target video frame, including: The target graphics rendering instructions are mapped to native interface instructions supported by the second graphics processor; Based on the rendering context information carried by the target graphics rendering instruction, the rendering pipeline is reconstructed on the second graphics processor; Based on the rendering pipeline, the local interface instructions are executed to obtain the target video frame.

9. A graphics rendering device, applied to a first terminal, characterized in that, include: A determining module is used to determine the instruction received by the first graphics processor that meets preset conditions as the target graphics rendering instruction; wherein, the first graphics processor is installed in the first terminal; The first sending module is used to send the target graphics rendering instruction to the second terminal; The first receiving module is used to receive and display the target video frame generated by the second terminal based on the target graphics rendering instruction.

10. A graphics rendering device, applied to a second terminal, characterized in that, include: The second receiving module is used to receive the target graphics rendering command sent by the first terminal; The graphics rendering module is used to reconstruct the rendering pipeline and perform graphics rendering on the second graphics processor installed on the second terminal based on the target graphics rendering instructions to obtain the target video frame. The second sending module is used to send the target video frame to the first terminal.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the graphics rendering method as described in any one of claims 1 to 8.

Images