Rendering method and electronic equipment

Abstract

The invention discloses a rendering method and electronic equipment. According to the electronic equipment, the GPU is called to render the user interface under the condition that the GPU can perform correct rendering, and the CPU is called to render the user interface under the condition that the GPU cannot perform correct rendering, so that efficient rendering is realized by utilizing the hardware acceleration characteristic of the GPU, the rendering accuracy is ensured by utilizing the CPU, the rendering efficiency and the rendering effect can be considered, and good equipment use experience is provided for a user.

Description

Technical Field

[0001] This application relates to the field of terminals and the field of image processing, and particularly to a rendering method and an electronic device. Background Art

[0002] When electronic devices such as mobile phones, tablet computers, and desktop computers display the user interface of an application, rendering is a very important step. Accurately and efficiently rendering the image can provide users with an excellent usage experience. Summary of the Invention

[0003] This application provides a rendering method and an electronic device, which can balance the rendering efficiency and the rendering effect, and provide users with a good device usage experience.

[0004] In a first aspect, a rendering method is provided, which is applied to an electronic device including a GPU and a CPU. The method may include: generating a first instruction, the first instruction instructing to call a first interface to render a first image frame of an application; calling the GPU to render the first image frame according to the first instruction; generating a second instruction, the second instruction instructing to call a second interface to render a second image frame of the application; calling the CPU to render the second image frame according to the second instruction.

[0005] Implementing the method of the first aspect, when the electronic device renders different image frames of the same application, it not only utilizes the hardware acceleration characteristics of the GPU to achieve efficient rendering, but also utilizes the CPU to ensure the accuracy of rendering, and can ensure the rendering effect.

[0006] In combination with the first aspect, in some embodiments, the first interface can be implemented by the GPU, and the second interface cannot be implemented by the GPU. Equivalently, when the GPU can render, the electronic device calls the GPU to render the image frame, and when the GPU cannot render, the CPU is called to render the image frame, that is, it utilizes the hardware acceleration characteristics of the GPU to achieve efficient rendering, and also utilizes the CPU to ensure the accuracy of rendering, and can ensure the rendering effect.

[0007] In combination with the first aspect, in some embodiments, the electronic device stores a whitelist, the whitelist includes the first interface and does not include the second interface; or, the electronic device stores a blacklist, the blacklist includes the second interface and does not include the first interface.

[0008] In combination with the first aspect, in some embodiments, the GPU supports a first graphics rendering standard and does not support a second graphics rendering standard.

[0009] In some embodiments, the application in the first aspect is an application developed based on the second graphics rendering standard, and both the first interface and the second interface belong to the interfaces based on the second graphics rendering standard.

[0010] In some embodiments, the first graphics rendering standard is Vulkan, and the second graphics rendering standard is OpenGL.

[0011] In some embodiments, the GPU includes a first interface and does not include a fourth interface. The fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function.

[0012] In some embodiments, the electronic device does not support converting the second interface to the fourth interface. The fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function.

[0013] In some embodiments, the electronic device can, according to a first instruction, call a third interface of the GPU to render a first image frame. The third interface is an interface based on the first graphics rendering standard, and the third interface and the first interface provide the same function. That is, the electronic device can convert the first interface to the third interface of the first graphics rendering standard.

[0014] In some embodiments, the electronic device can, according to a second instruction, call the CPU to render a second image frame. That is, the electronic device can call the CPU to implement the second interface.

[0015] In some embodiments, Mesa is included in the electronic device, and Mesa includes Zink and Swrast. The electronic device can convert the first interface to the third interface through Zink and call the third interface of the GPU through Zink; call the CPU through Swrast to implement the second interface.

[0016] In some embodiments, a context also needs to be introduced in the rendering process. Specifically, the electronic device can also generate a first context for the first image frame. The first context is in the Zink format and is used for Zink to call the third interface of the GPU. The electronic device can also generate a second context for the second image frame. The second context is in the Swrast format and is used for Swrast to call the CPU to implement the second interface.

[0017] In some embodiments, if the second image frame is an adjacent image frame after the first image frame, the electronic device can first generate a third context in the Zink format based on the first context and the image data of the second image frame; then convert the third context in the Zink format to the second context in the Swrast format.

[0018] In some embodiments, the method of the first aspect may further include the following steps: generating a third instruction that instructs to call a fifth interface to render a third image frame of the application; generating a fourth context in Swrast format based on the second context and the image data of the third image frame; converting the fourth context in Swrast format into a fifth context in Zink format; and rendering the third image frame by calling the GPU according to the fifth context through Zink. In this process, the electronic device converts the context in Swrast format into a context in Zink format.

[0019] Combined with the previous embodiment, the fifth interface may be an interface based on the second image rendering standard. The electronic device may call a sixth interface of the GPU according to the fifth context to render the third image frame. Among them, the sixth interface and the fifth interface provide the same function, and the sixth interface is an interface based on the first graphics rendering standard.

[0020] In some embodiments, before generating the first instruction, the electronic device may first load Zink and Swrast and initialize the rendering environments of Zink and Swrast. This can prepare for subsequent rendering operations in advance.

[0021] In some embodiments, the electronic device stores an application whitelist that includes the applications in the first aspect. Equivalently, only the applications in the whitelist can use the method of the first aspect to render image frames. The applications in the whitelist can be obtained by developers through prior experiments and may include application programs with a high degree of compatibility with Zink.

[0022] In some embodiments, after rendering the first image frame, the electronic device may further display the first image frame; after rendering the second image frame, the electronic device may further display the second image frame. Sending the rendering result for display can provide a good device usage experience for the user.

[0023] In a second aspect, a rendering method is provided, which is applied to an electronic device including a GPU, a CPU, and a display screen. The GPU supports Vulkan but does not support OpenGL. The method may include: starting a first application, where the first application is an application developed based on OpenGL; obtaining a first instruction for the first application to call a first OpenGL API to render a first image frame, and calling a first Vulkan API of the GPU to render the first image frame, where the first Vulkan API and the first OpenGL API provide the same function; displaying the first image frame on the display screen; obtaining a second instruction for the first application to call a second OpenGL API to render a second image frame, and calling the CPU to implement the second OpenGL API to render the second image frame; and displaying the second image frame on the display screen.

[0024] When implementing the method of the second aspect, when the electronic device renders different image frames of the same application, it not only utilizes the hardware acceleration characteristics of the GPU to achieve efficient rendering, but also utilizes the CPU to ensure the accuracy of rendering, thus ensuring the rendering effect.

[0025] Combined with the second aspect, in some embodiments, the electronic device stores a whitelist of OpenGL APIs. The whitelist of OpenGL APIs includes the first OpenGL API and does not include the second OpenGL API; or, the electronic device stores a blacklist of OpenGL APIs. The blacklist of OpenGL APIs includes the second OpenGL API and does not include the first OpenGL API.

[0026] Combined with the second aspect, in some embodiments, the GPU includes the first Vulkan API and does not include the second Vulkan API. The second Vulkan API and the second OpenGL API provide the same functions.

[0027] Combined with the second aspect, in some embodiments, the electronic device does not support converting the second OpenGL API to the second Vulkan API.

[0028] Through any one of the above two embodiments, the electronic device preferentially uses Zink to render the user interface. When Zink can render correctly, it renders the user interface based on Zink. When Zink cannot render correctly, it renders the user interface based on Swrast. In this way, it not only utilizes the hardware acceleration characteristics of Zink to achieve efficient rendering, but also utilizes Swrast to ensure the accuracy of rendering.

[0029] Combined with the second aspect, in some embodiments, the electronic device includes Mesa, and Mesa includes Zink and Swrast; the electronic device can convert the first OpenGL API to the first Vulkan API through Zink and call the first Vulkan API of the GPU through Zink; the electronic device can also call the CPU through Swrast to implement the second OpenGL API.

[0030] Combined with the previous embodiment, in some embodiments, after obtaining the first instruction, the electronic device can also generate a first context of the first image frame, and the first context is in the Zink format; the electronic device can call the first Vulkan API of the GPU through Zink according to the first context. After obtaining the second instruction, the electronic device can also generate a second context of the second image frame, and the second context is in the Swrast format; the electronic device can call the CPU through Swrast to implement the second OpenGL API according to the second context.

[0031] In combination with the previous embodiment, if the second image frame is an adjacent image frame after the first image frame, the electronic device may generate a third context in Zink format based on the first context and the data of the second image frame; and convert the third context in Zink format into a second context in Swrast format.

[0032] In combination with the previous embodiment, the method may further include: obtaining a third instruction for the first application to call a third OpenGL API to render a third image frame; generating a fourth context in Swrast format based on the second context and the data of the third image frame; converting the fourth context in Swrast format into a fifth context in Zink format; calling a third Vulkan API of the GPU through Zink according to the fifth context to render the third image frame, where the third Vulkan API and the third OpenGL API provide the same function; and displaying the third image frame on the display screen.

[0033] In some embodiments, after starting the first application, the electronic device may load Zink and Swrast, and initialize the rendering environments of Zink and Swrast.

[0034] In combination with the second aspect, in some embodiments, the electronic device pre-stores an application whitelist, and the application whitelist includes the first application.

[0035] In combination with the second aspect, in some embodiments, the method may further include: starting a second application, where the second application supports OpenGL; obtaining instructions for the second application to call multiple OpenGL APIs to render multiple image frames, and calling multiple Vulkan APIs of the GPU to render multiple image frames, where the multiple Vulkan APIs and the multiple OpenGL APIs provide the same function; and displaying the multiple image frames on the display screen.

[0036] In a third aspect, there is provided an electronic device, which includes a GPU, a CPU, one or more processors, and one or more memories; wherein, the GPU, the CPU, the memory are coupled to the processor, and the one or more memories are used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device is caused to execute the method described in the first aspect, or any possible implementation manner in the first aspect, or the second aspect, or any possible implementation manner in the second aspect.

[0037] Fourthly, a chip system is provided. The chip system is applied to an electronic device and includes one or more processors for invoking computer instructions to cause the electronic device to execute the method described in the first aspect, or any possible implementation manner in the first aspect, or the second aspect, or any possible implementation manner in the second aspect.

[0038] Fifthly, a computer-readable storage medium is provided, including instructions which, when running on an electronic device, cause the electronic device to execute the method described in the first aspect, or any possible implementation manner in the first aspect, or the second aspect, or any possible implementation manner in the second aspect.

[0039] Sixthly, a computer program product containing instructions is provided which, when running on an electronic device, cause the electronic device to execute the method described in the first aspect, or any possible implementation manner in the first aspect, or the second aspect, or any possible implementation manner in the second aspect. Description of the Drawings

[0040] Figure 1 It is a software architecture diagram of the electronic device provided in the embodiments of this application;

[0041] Figure 2 It is a comparison diagram of the rendering effect of the rendered picture provided in the embodiments of this application;

[0042] Figure 3 It is a flowchart of the rendering method provided in the embodiments of this application;

[0043] Figure 4 It is a flowchart of constructing gl_context_Zink and gl_context_SW provided in the embodiments of this application;

[0044] Figure 5 It is a flowchart of the rendering method provided in the embodiments of this application;

[0045] Figure 6 It is a hardware structure block diagram of the electronic device provided in the embodiments of this application. Detailed Embodiments

[0046] Next, the technical solutions in the embodiments of this application will be clearly and elaborately described with reference to the drawings.

[0047] First, several concepts related to this application are introduced.

[0048] Application Programming Interface (API)

[0049] An API is an interface provided by an operating system for applications to call. Applications can execute their commands by calling the API. An API can be regarded as a collection of a set of programs and protocols. The API enables communication between computer software.

[0050] Open Graphics Library (OpenGL)

[0051] OpenGL defines a set of standard APIs for 2D or 3D graphics rendering that are cross - programming - language and cross - platform. Upper - layer OpenGL applications can call the OpenGL API to render the user interface. An OpenGL application refers to an application developed according to the interface standards defined by OpenGL, such as some 3D computer game applications, browser applications, etc. In the embodiments of the present application, OpenGL can be a standard API library compiled based on Mesa, and the definition of Mesa can be referred to the introduction later.

[0052] If a hardware manufacturer develops a GPU according to the interface standards defined by OpenGL, then the GPU supports OpenGL and can provide the OpenGL API, and upper - layer OpenGL applications can call the OpenGL API of this GPU to render the user interface.

[0053] Vulkan

[0054] Vulkan defines a set of cross - platform standard APIs for 2D or 3D graphics rendering. Upper - layer Vulkan applications can call the Vulkan API to render the user interface. A Vulkan application refers to an application developed according to the interface standards defined by Vulkan.

[0055] If a hardware manufacturer develops a GPU according to the interface standards defined by Vulkan, then the GPU supports Vulkan and can provide the Vulkan API, and upper - layer Vulkan applications can call the Vulkan API of this GPU to render the user interface.

[0056] Vulkan and OpenGL define two different API standards. Vulkan has lower central processing unit (CPU) overhead and more efficient GPU control, and is a popular trend for future API standards.

[0057] From the above content, it can be seen that upper - layer applications and the underlying GPUs need to maintain the same API standard to complete graphics rendering. For example, both adopt the standards defined by OpenGL, or both adopt the standards defined by Vulkan.

[0058] Mesa

[0059] Mesa, also known as Mesa3D or the Mesa 3D Graphics Library module, is an open-source software implementation of OpenGL, Vulkan, and other graphics API specifications. Mesa implements a conversion layer between a graphics API (such as the OpenGL API) and the graphics hardware driver of the operating system kernel. The main purpose of Mesa is to facilitate application vendors who are not yet capable of migrating to the Vulkan API and help them implement the OpenGL API. That is, application vendors can still develop applications based on OpenGL, and these applications can run on electronic devices that contain a GPU that supports Vulkan but not OpenGL, and also contain Mesa, which can be used to implement the OpenGL API called by the application.

[0060] Mesa contains two parts, Zink and Swrast, which are used to implement the OpenGL API called by OpenGL applications in different ways.

[0061] Zink

[0062] Zink is an OpenGL driver implemented based on Vulkan in Mesa, and can also be called a hard driver. Essentially, it is an API conversion layer. Zink can run on any Vulkan hardware (such as a GPU that supports Vulkan). Zink is used to call the Vulkan API provided by the GPU, and then implement the corresponding OpenGL API of the Vulkan API. The corresponding Vulkan API and OpenGL API provide the same capabilities and implement the same functions, but they only have different execution standards.

[0063] Swrast

[0064] Swrast is an OpenGL driver implemented based on the CPU in Mesa, and can also be called a soft driver. Swrast can run on the CPU, and Swrast is used to directly call the CPU to implement the OpenGL API.

[0065] Compared with Zink and Swrast, Zink calls the GPU to complete rendering, while Swrast calls the CPU to complete rendering. The rendering efficiency of the GPU is higher than that of the CPU. Therefore, Zink has a higher rendering efficiency than Swrast. Using Zink to complete rendering is also equivalent to using the GPU for hardware rendering acceleration.

[0066] Currently, there are still a large number of applications developed based on OpenGL, and there are also a large number of hardware manufacturers producing GPUs that only support Vulkan and do not support OpenGL. Electronic devices installed with OpenGL applications but configured with GPUs that do not support OpenGL but support Vulkan are widely used. How such electronic devices render the user interface of OpenGL applications has a great impact on the user experience. The GPUs mentioned later in this application are all GPUs that do not support OpenGL but support Vulkan. Such GPUs are equipped with or contain the Vulkan API library, provide the Vulkan API, and do not contain the OpenGL API library and do not provide the OpenGL API. An example of an OpenGL application can be an application using the X11 protocol. The X11 protocol is a protocol for applications to display graphics.

[0067] The following introduces two solutions for rendering the user interface of OpenGL applications in combination with the software structure of the electronic device.

[0068] Refer to Figure 1 , Figure 1 which exemplarily shows the software architecture of the electronic device. The software operating system (OS) of the electronic device provided in this application may include but is not limited to etc.

[0069] As Figure 1 shown, this software architecture shows the hierarchical relationship between the OpenGL application, Mesa, and the GPU and CPU. As Figure 1 shown, the OpenGL application is located in the application layer, Mesa is located in the display framework layer, including Zink and Swrast, and the GPU and CPU are located in the bottom hardware layer. Among them, the GPU is the GPU mentioned above that does not support OpenGL and only supports Vulkan.

[0070] One rendering solution is to render the user interface of the OpenGL application based on Swrast. As Figure 1 shown, after the OpenGL application is started, enable Swrast in Mesa. Mesa can select Swrast to call the underlying CPU, specifically by calling the swrast.so library. The swrast.so library calls the CPU and uses the capabilities of the CPU to calculate and generate the rendered image. In this way, the OpenGL API called by the OpenGL application can be implemented to render the user interface of the OpenGL application. Since the rendering efficiency of the CPU is relatively low, the overall efficiency of this solution is not high.

[0071] Another rendering solution is to render the user interface of the OpenGL application (such as an application using the X11 protocol) based on Zink. AsFigure 1 As shown, after the OpenGL application is started, Zink in Mesa is enabled. Mesa can select Zink to convert the OpenGL API called by the OpenGL application into the Vulkan API, and then call the Vulkan API of the underlying GPU to implement the OpenGL API called by the OpenGL application, thereby rendering the user interface of the OpenGL application. The Vulkan API configured in some GPUs is not complete enough, or the GPU's support for Vulkan is insufficient, or Zink itself makes an error when converting the OpenGL API into the Vulkan API, which may cause an error when Zink renders the user interface, resulting in an abnormal user interface displayed on the electronic device and affecting the user experience. It can be seen that although this solution uses Zink to achieve hardware rendering acceleration of the GPU and improves the rendering efficiency, it may cause rendering errors in some of the above-listed cases.

[0072] Comparing the two rendering solutions, it can be seen that Swrast implements the OpenGL API through the CPU, and Zink implements the OpenGL API through the GPU.

[0073] Reference Figure 2 , Figure 2 a of Figure 2 exemplarily shows the user interface displayed on the electronic device when rendering fails based on Zink. As shown in a of

[0074] The following embodiments of the present application provide a rendering method, which can solve the deficiencies of the above two rendering solutions, balance the rendering efficiency and rendering effect, and provide a good device usage experience for users. In this method, the electronic device combines Swrast on the basis of Zink to complete rendering. The electronic device preferentially uses Zink to render the user interface. When Zink can render correctly, it renders the user interface based on Zink. When Zink cannot render correctly, it renders the user interface based on Swrast. In this way, it not only utilizes the hardware acceleration characteristics of Zink to achieve efficient rendering, but also utilizes Swrast to ensure the accuracy of rendering.

[0075] Figure 3 Exemplarily shows the flow of the rendering method provided by the embodiments of the present application. As shown in Figure 3 , the method may include the following steps:

[0076] S101, the electronic device starts a first application, and the first application is an OpenGL application.

[0077] The electronic device can receive user operations, such as an operation of clicking on the icon of the first application on the desktop or a voice command, etc. In response to this user operation, the electronic device starts the first application. An OpenGL application refers to an application program developed according to the interface standard defined by OpenGL, and the OpenGL application supports OpenGL.

[0078] S102, Mesa determines whether to enable Zink. If not, then S103 is executed; if so, then S104 is executed.

[0079] The electronic device may store a preset application whitelist, and the application whitelist may include one or more application programs. Mesa can read the application whitelist. If the first application started by the electronic device belongs to the application whitelist, it is considered that Zink needs to be enabled, and subsequently, the solution combining Zink and Swrast provided in this application is used to render the user interface; if the first application does not belong to the application whitelist, it is considered that Zink does not need to be enabled, and Swrast is used to render the user interface subsequently.

[0080] The application programs in the application whitelist can be obtained by the R & D personnel through prior experiments, and these application programs may include application programs with a high degree of adaptation to Zink.

[0081] S102 is an optional step. In some embodiments, S102 may not be executed either. After the electronic device starts the OpenGL application, S103 and subsequent steps can be directly executed.

[0082] S103, Mesa uses Swrast to render the user interface.

[0083] Mesa can read and run the execution code of Swrast from the memory to load Swrast. Then, Mesa can initialize the rendering environment of Swrast, construct a context in Swrast format, and then call the CPU according to the context in Swrast format, and use the CPU to implement the OpenGL API called by the first application, thereby rendering the user interface of the first application.

[0084] S104, Mesa reads and runs the execution codes of Zink and Swrast from the memory to load Zink and Swrast respectively.

[0085] S105, Mesa initializes the rendering environments of Zink and Swrast.

[0086] Initializing the rendering environment can lay the foundation for subsequent rendering operations. Initialization may include creating a context, setting the initial state of the context, etc. The context is the data required for rendering preparation, which may include data related to view settings (such as orthographic or projection mode, viewport parameters), color buffer attributes, depth buffer attributes, lighting attributes, texture attribute buffer data (such as vertex buffer, index buffer), matrix data (such as rotation, translation, scaling operations), clipping data, transparency data, shader data, vertex coordinates, etc. Among them, the vertex buffer is used to store vertex data, and the index buffer is used to store indices. The electronic device can use default data to construct the context of the initial state. The context of the initial state can be denoted as gl_context.

[0087] Executing S105 is equivalent to Mesa loading Zink and Swrast simultaneously and initializing the rendering environments of Zink and Swrast at the same time.

[0088] S106, set the current context to the Zink format.

[0089] Since the rendering method provided by the embodiments of the present application mainly uses Zink rendering, the context is initially set to the Zink format. The same context data can be constructed into different formats for different modules to call. For example, the context in the Zink format can be used to render images in Zink, and the context in the Swrast format can be used to render images in Swrast. The context in the Zink format refers to the context constructed according to the standards specified by Zink, and the context in the Swrast format refers to the context represented according to the standards specified by Swrast. The current context format and content can be changed. At different time points, there can be different context formats and different context contents. At the time node of S106, the current context is the context initialized in S105.

[0090] S107, the first application sends the image data of the current frame to Mesa.

[0091] The first application can send image data to Mesa frame by frame. The image data of one frame may include the view data, buffer data, matrix data, shader data, vertex coordinates, etc. of this frame.

[0092] S108, Mesa fills the image data sent by the first application into the current context.

[0093] If the first application sends image data for the first time after startup, Mesa uses this image data to refresh the initialized Zink-format context to obtain a new filled Zink-format context.

[0094] If the image data is not sent for the first time after the first application is launched, Mesa uses the image data to refresh the current context and obtains a new filled context. If the image data is not sent for the first time after the first application is launched, it means that the first application has rendered one or more frames of images before. Then, the current context obtained after refreshing contains the data of the most recently rendered image and the image data of the current frame newly sent by the first application. And the current context may be in the Zink format or the Swrast format.

[0095] S109, the first application calls the first OpenGL API to render the current frame.

[0096] According to the actual situation of different frames, the first application can call the same or different OpenGL APIs to render different frames. The number of OpenGL APIs called when rendering a frame of image can be one or multiple. That is, the first OpenGL API can include one or more OpenGL APIs.

[0097] S110, Mesa determines whether the current frame can be correctly rendered by calling Zink.

[0098] The reasons why a frame of image cannot be correctly rendered by calling Zink may include but are not limited to the following: 1. The Vulkan API library configured in the GPU is not complete enough or the GPU's support for Vulkan is not sufficient. Then, the Vulkan API library in the GPU may not contain the Vulkan API converted from the first OpenGL API, and thus it is impossible to call this Vulkan API to implement the first OpenGL API, and thus impossible to render. 2. Zink itself makes an error when converting the first OpenGL API to the Vulkan API. If the first OpenGL API includes multiple OpenGL APIs, the converted Vulkan API can also include multiple.

[0099] In some embodiments, the electronic device can pre-store a whitelist of OpenGL APIs. The whitelist can contain one or more OpenGL APIs that can be correctly rendered by calling Zink. The electronic device can check whether the whitelist contains the first OpenGL API. If it does, it is considered that the judgment result of S110 is yes. In other embodiments, the electronic device can pre-store a blacklist of OpenGL APIs. The blacklist can contain one or more OpenGL APIs that cannot be correctly rendered by calling Zink. The electronic device can check whether the blacklist contains the first OpenGL API. If it does not, it is considered that the judgment result of S110 is yes. The above whitelist or blacklist can be obtained by R & D personnel through experiments in advance.

[0100] If the judgment result of S110 is yes, Mesa will call Zink to complete the rendering of the current frame, which can not only ensure the accuracy of the rendering result but also improve the rendering efficiency by using the GPU. The detailed operations for Mesa to call Zink to complete the rendering of the current frame can be referred to S111 - S114.

[0101] If the judgment result of S110 is no, Mesa will call Swrast to complete the rendering of the current frame, which can ensure the accuracy of the rendering result. The detailed operations for Mesa to call Swrast to complete the rendering of the current frame can be referred to S115 - S118.

[0102] S111, Mesa determines whether the previous frame was rendered based on Swrast.

[0103] If so, the current context is a Swrast - formatted context (which can be denoted as gl_context_SW), and the electronic device will execute S112 - S114 to construct the current context in Zink format; if not, the current context is a Zink - formatted context (which can be denoted as gl_context_Zink), and the electronic device will execute S114 and directly use the current Zink - formatted context.

[0104] S112, Mesa constructs a Zink - formatted context based on the current Swrast - formatted context, that is, converts gl_context_SW to gl_context_Zink.

[0105] The specific operations to convert gl_context_SW to gl_context_Zink may include: extracting driver - independent data from gl_context_SW, such as color buffer attributes, depth buffer attributes, lighting attributes, texture attributes, etc.; extracting driver - related data in gl_context_SW, such as vertex buffer data, shader data (such as vertex shader, fragment shader), etc., using the Zink driver data constructor, taking the extracted driver - related data as the input parameters of this function, and obtaining the Zink - formatted driver - related data output by this function; finally, merging the above - mentioned driver - independent data and the Zink - formatted driver - related data to obtain gl_context_Zink.

[0106] Reference Figure 4 of a, Figure 4 of a exemplarily shows the flowchart for Mesa to convert gl_context_SW to gl_context_Zink. As Figure 4As shown in a of, Mesa can first construct the driver-independent data in gl_context_Zink, such as color buffer attributes, etc. Specifically, it can extract the driver-independent data from gl_context_SW as the data in gl_context_Zink; then, Mesa can successively construct the driver-dependent data in gl_context_Zink, such as vertex buffer data, shader data, etc. As Figure 4 As shown in a of, taking the construction of vertex buffer data as an example, Mesa can first obtain the vertex buffer data from gl_context_SW and input the vertex buffer data into the Zink driver data construction function to obtain the vertex buffer data in gl_context_Zink.

[0107] S113, Mesa sets the converted Zink-format context (gl_context_Zink) as the new current context.

[0108] S112 and S113 can be executed by Gallium in Mesa, and Gallium is located one level above Zink and Swrast in Mesa.

[0109] S114, Mesa calls Zink, and Zink calls the first Vulkan API to render the current frame according to the current context. The first Vulkan API is the Vulkan API provided by the GPU corresponding to the first OpenGL API.

[0110] Specifically, Zink converts the first OpenGL API into the first Vulkan API, then calls the first Vulkan API of the GPU, and realizes the first OpenGL API through the first Vulkan API, thereby rendering the current frame. The first Vulkan API corresponds to the first OpenGL API, and the GPU calling the first Vulkan API can realize the same function as the first OpenGL API.

[0111] Execute this branch of S110 - S114. If the previously called OpenGL API is rendered through Swrast and the currently called OpenGL API can be rendered through Zink, the electronic device will switch from Swrast to Zink and use Zink to complete the rendering of the current frame; if the previously called OpenGL API is rendered through Zink and the currently called OpenGL API can be rendered through Zink, the electronic device will continue to use Zink to complete the rendering of the current frame.

[0112] In some embodiments, S111 can also be replaced by determining whether the previous frame is rendered based on Zink. If so, S118 is executed; if not, S116 - S118 are executed.

[0113] S115, Mesa determines whether the previous frame is rendered based on Zink.

[0114] If so, the current context is a context in Zink format (which can be denoted as gl_context_Zink), and the electronic device will execute S116 - S118 to construct the current context in Swrast format; if not, the current context is a context in Swrast format (which can be denoted as gl_context_Swrast), and the electronic device will execute S118 and directly use the current Swrast - format context.

[0115] S116, Mesa constructs a context in Swrast format based on the current context in Zink format, that is, converts gl_context_Zink to gl_context_Swrast.

[0116] The specific operations of S116 are similar to those of S112. The specific operations of converting gl_context_Zink to gl_context_SW may include: extracting data independent of the driver from gl_context_Zink, such as color buffer attributes, depth buffer attributes, lighting attributes, texture attributes, etc.; extracting data related to the driver in gl_context_Zink, such as vertex buffer data, shader data (such as vertex shader, fragment shader), etc., using the Swrast driver - data constructor, taking the extracted driver - related data as the input parameters of this function, and obtaining the Swrast - format driver - related data output by this function; finally, merging the above - mentioned driver - independent data and the Swrast - format driver - related data to obtain gl_context_SW.

[0117] Reference Figure 4 of b, Figure 4 of b exemplarily shows the flowchart of Mesa converting gl_context_Zink to gl_context_SW. As Figure 4 shown in b of, Mesa can first construct the data independent of the driver in gl_context_SW, such as color buffer attributes, etc., and specifically can extract the data independent of the driver from gl_context_Zink as the data in gl_context_SW; then, Mesa can sequentially construct the data related to the driver in gl_context_SW, such as vertex buffer data, shader data, etc. As Figure 4As shown in b), taking the construction of vertex buffer data as an example, Mesa can first obtain the vertex buffer data from gl_context_Zink and input the vertex buffer data into the Swrast driver data constructor to obtain the vertex buffer data in gl_context_SW.

[0118] S117, Mesa sets the converted Swrast format context (gl_context_Swrast) as the new current context.

[0119] S116 and S117 can be executed by Gallium in Mesa.

[0120] S118, Mesa calls Swrast, and Swrast calls the CPU to implement the first OpenGL API according to the current context to render the current frame.

[0121] Specifically, Swrast directly calls the CPU to implement the first OpenGL API, thereby rendering the current frame.

[0122] Execute this branch of S110, S115 - S118. If the previous call to the OpenGL API was rendered through Zink and the current call to the OpenGL API cannot be rendered through Zink, the electronic device will switch from Zink to Swrast and use Swrast to complete the rendering of the current frame; if the previous call to the OpenGL API was rendered through Swrast and the current call to the OpenGL API also cannot be rendered through Zink, the electronic device will continue to use Swrast to complete the rendering of the current frame.

[0123] In some embodiments, S115 can also be replaced by determining whether the previous frame was rendered based on Swrast. If so, execute S118; if not, execute S116 - S118.

[0124] S119, the GPU or CPU sends the rendering result for display, and a user interface including the current frame is displayed on the display screen.

[0125] So far, Mesa in the electronic device has completed the rendering of the current frame by calling Zink or Swrast. After S114 or S118, the electronic device will continue to render the next frame and execute the steps of S117 - S119 again for the next frame, so as to render and display the user interface of the first application frame by frame.

[0126] By Figure 3In the rendering method shown, the electronic device preferentially uses Zink to render the user interface. Specifically, the user interface is rendered based on Zink when Zink can render correctly, and is rendered based on Swrast when Zink cannot render correctly. This not only utilizes the hardware acceleration feature of Zink to achieve efficient rendering, but also uses Swrast to ensure the accuracy of rendering, which can improve the user experience.

[0127] refer to Figure 2 , Figure 2 FIG. b exemplarily shows a user interface rendered based on the rendering method of the present application. Figure 2 As shown in b, the user interface displayed by the electronic device is continuous, and the colors and contents are smooth and accurate.

[0128] refer to Figure 5 , Figure 5 A flowchart of another rendering method provided in an embodiment of the present application.

[0129] like Figure 5 As shown, the method takes at least two rendering operations as an example to introduce the rendering method provided by the embodiment of the present application. The method may include the following steps:

[0130] S201, the electronic device generates a first instruction, where the first instruction instructs calling a first interface to render a first image frame of an application.

[0131] S202: The electronic device calls a GPU of the electronic device to render a first image frame according to a first instruction.

[0132] S203: The electronic device generates a second instruction, where the second instruction instructs calling a second interface to render a second image frame of the application.

[0133] S204: The electronic device calls the CPU of the electronic device to render a second image frame according to the second instruction.

[0134] The first instruction and the second instruction are both generated by the same application. The generation time of the two instructions can be Figure 3 For the execution time of S109, please refer to S109 and related descriptions.

[0135] pass Figure 5 With the method shown, when the electronic device renders different image frames of the same application, it not only utilizes the hardware acceleration feature of the GPU to achieve efficient rendering, but also utilizes the CPU to ensure the accuracy of rendering, thereby ensuring the rendering effect.

[0136] In some embodiments, the first interface can be implemented by the GPU, and the second interface cannot be implemented by the GPU. That is, when the GPU can render, the electronic device calls the GPU to render the image frame, and when the GPU cannot render, the CPU is called to render the image frame. This not only utilizes the hardware acceleration feature of the GPU to achieve efficient rendering but also uses the CPU to ensure the accuracy of rendering, thus guaranteeing the rendering effect.

[0137] In some embodiments, the electronic device can determine whether an interface can be implemented by the GPU through an interface list. For example, the electronic device stores a whitelist that includes the first interface and does not include the second interface; or, the electronic device stores a blacklist that includes the second interface and does not include the first interface. The implementation method of the interface list can refer to the relevant description of S110 in Figure 3 which.

[0138] In some embodiments, the GPU supports the first graphics rendering standard and does not support the second graphics rendering standard.

[0139] In some embodiments, Figure 5 the application in is an application developed based on the second graphics rendering standard, and both the first interface and the second interface belong to the interfaces based on the second graphics rendering standard. An example of this application can refer to the first application in Figure 3 which.

[0140] In some embodiments, the first graphics rendering standard is Vulkan, and the second graphics rendering standard is OpenGL. Of course, it is not limited to these two graphics rendering standards. The first graphics rendering standard and the second graphics rendering standard in the embodiments of the present application can also be implemented as other different graphics rendering standards.

[0141] In some embodiments, the first graphics rendering standard is Vulkan, and the second graphics rendering standard is OpenGL. A specific example of this embodiment can refer to Figure 3 .

[0142] In some embodiments, the GPU includes the first interface and does not include the fourth interface. The fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function; or, the electronic device does not support converting the second interface to the fourth interface. The fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function. This embodiment can be used to determine whether the interface called by the application can be implemented by the GPU, and its judgment logic can refer to S110 in Figure 3 which.

[0143] In some embodiments, when the electronic device executes S202, it may, according to the first instruction, call the third interface of the GPU to render the first image frame. The third interface is an interface based on the first graphics rendering standard, and the third interface and the first interface provide the same functions. That is, the electronic device can convert the first interface into the third interface of the first graphics rendering standard. This conversion operation can refer to Figure 3 S114 in

[0144] In some embodiments, when the electronic device executes S204, it may, according to the second instruction, call the CPU of the electronic device to render the second image frame. That is, the electronic device can call the CPU to implement the second interface. This operation can refer to Figure 3 S118 in

[0145] In some embodiments, Mesa is included in the electronic device, and Mesa includes Zink and Swrast. The electronic device can convert the first interface into the third interface through Zink and call the third interface of the GPU through Zink; call the CPU through Swrast to implement the second interface. This embodiment can refer to Figure 3 S111 - S114 and S115 - S118 in

[0146] In some embodiments, the rendering process also needs to introduce a context. Specifically, before S202, the electronic device can also generate the first context of the first image frame. The first context is in Zink format and is used for Zink to call the third interface of the GPU. Before S204, the electronic device can also generate the second context of the second image frame. The second context is in Swrast format and is used for Swrast to call the CPU to implement the second interface. The generation method of the context can refer to Figure 3 S107 - S118 in

[0147] In some embodiments, if the second image frame is an adjacent image frame after the first image frame, the electronic device can first generate a third context in Zink format according to the first context and the image data of the second image frame; then convert the third context in Zink format into a second context in Swrast format. This conversion process of the context format can refer to Figure 3 S115 - S118 in

[0148] In some embodiments, Figure 5The method shown may further include the following steps after S204: generating a third instruction, the third instruction instructing to call a fifth interface to render a third image frame of the application; generating a fourth context in Swrast format according to the second context and the image data of the third image frame; converting the fourth context in Swrast format into a fifth context in Zink format; and rendering the third image frame by calling the GPU according to the fifth context through Zink. During this process, the electronic device converts the context in Swrast format into a context in Zink format, and this conversion process may refer to Figure 3 S111 - S114 in

[0149] Combined with the previous embodiment, the fifth interface may be an interface based on the second image rendering standard. The electronic device may call a sixth interface of the GPU according to the fifth context to render the third image frame. Among them, the sixth interface and the fifth interface provide the same function, and the sixth interface is an interface based on the first graphics rendering standard.

[0150] In some embodiments, before executing Figure 5 S201, the electronic device may first load Zink and Swrast and initialize the rendering environments of Zink and Swrast. The process of loading and initializing may refer to Figure 3 S104 - S105 in

[0151] In some embodiments, the electronic device stores an application whitelist, and the application whitelist contains the applications in Figure 5 . That is, only the applications in the whitelist can use the method shown in Figure 5 to render image frames. The applications in the whitelist can be obtained by developers through experiments in advance, and may include application programs with a high degree of adaptation to Zink.

[0152] In some embodiments, after rendering the first image frame, the electronic device may further display the first image frame; after rendering the second image frame, the electronic device may further display the second image frame.

[0153] This application also provides an electronic device for executing the rendering method introduced above.

[0154] The electronic device provided by this application is a smart terminal device, which can be of various types. The embodiments of this application do not limit its specific type. For example, the electronic device can be a desktop computer, a desktop computer with a touch-sensitive surface or a touch panel, a laptop, a handheld computer, a notebook computer, a tablet computer, or it can also be a mobile phone, a smart screen, a wearable device (such as a smart watch, a smart bracelet, etc.), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a car computer, a smart headset, a game console, or it can also be an internet of things (IOT) device or a smart home device such as a smart water heater, a smart lamp, a smart air conditioner, and so on.

[0155] Reference Figure 6 , Figure 6 is the hardware structure diagram of the electronic device 100 provided by the embodiments of this application.

[0156] As Figure 6 shown, the electronic device 100 may include: The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone interface 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, etc. Among them, the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0157] It can be understood that the structure schematically shown in the embodiments of this application does not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than shown, or combine certain components, or split certain components, or have different component arrangements. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0158] The processor 110 may include one or more processing units. For example, the processor 110 may include a CPU, a modem processor, a GPU, an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors.

[0159] In the embodiment of this application, the GPU of the electronic device 100 does not support OpenGL and only supports Vulkan. The Vulkan API in the GPU can be called by Zink to implement the corresponding OpenGL API. The CPU can be directly called by Swrast to implement the OpenGL API.

[0160] The controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching and executing instructions.

[0161] A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can save the instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instruction or data again, it can be directly called from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0162] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0163] The charging management module 140 is configured to receive a charging input from a charger. The charger may be a wireless charger or a wired charger. In some embodiments of wired charging, the charging management module 140 may receive the charging input of the wired charger through the USB interface 130. In some embodiments of wireless charging, the charging management module 140 may receive the wireless charging input through the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 may also supply power to the electronic device through the power management module 141.

[0164] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives the inputs from the battery 142 and / or the charging management module 140 and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, the wireless communication module 160, etc. The power management module 141 may also be used to monitor parameters such as the battery capacity, the number of battery cycles, and the battery health status (leakage, impedance). In some other embodiments, the power management module 141 may also be disposed in the processor 110. In some other embodiments, the power management module 141 and the charging management module 140 may also be disposed in the same device.

[0165] The wireless communication function of the electronic device 100 may be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modulation and demodulation processor, and the baseband processor, etc.

[0166] Antenna 1 and Antenna 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example, Antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0167] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc. applied to the electronic device 100.

[0168] The wireless communication module 160 can provide solutions for wireless communications including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc. applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via Antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive the signals to be sent from the processor 110, frequency-modulate and amplify them, and convert them into electromagnetic waves via Antenna 2 for radiation.

[0169] In some embodiments, Antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and Antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technologies.

[0170] The electronic device 100 realizes the display function through the GPU, the display screen 194, and the application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change the display information.

[0171] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can adopt a liquid crystal display (LCD). The display panel can also adopt an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniled, a microled, a micro-oled, a quantum dot light-emitting diode (QLED), etc. for manufacturing. In some embodiments, the electronic device may include one or N display screens 194, where N is a positive integer greater than 1.

[0172] The electronic device 100 can implement the shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, and the application processor, etc.

[0173] The internal memory 121 may include one or more random access memories (RAM) and one or more non-volatile memories (NVM).

[0174] The random access memory can be directly read and written by the processor 110, and can be used to store the operating system or the executable programs of other running programs (such as machine instructions), and can also be used to store the data of users and application programs, etc.

[0175] The non-volatile memory can also store executable programs and store the data of users and application programs, etc., and can be pre-loaded into the random access memory for the processor 110 to directly read and write.

[0176] In the embodiments of the present application, the internal memory 121 may store program instructions for implementing the rendering method provided by the present application, and the processor 110 is used to call the program instructions to trigger the electronic device 100 to execute the rendering method. Specifically, the CPU in the processor 110 can be used to schedule each module of the electronic device 100, such as Mesa, Zink, Swrast, and the GPU, the display screen 194, etc., to execute Figure 3 the shown rendering method. The interaction of the above modules can refer to Figure 3 each step of. The internal memory 121 may also pre-store Figure 3The application whitelist involved in S102, and the whitelist or blacklist of the OpenGL API involved in S110.

[0177] The external memory interface 120 can be used to connect to an external non-volatile memory to implement the storage capacity expansion of the electronic device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to implement the data storage function. For example, files such as music and videos are saved in the external non-volatile memory.

[0178] The electronic device 100 can implement audio functions through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor, etc. For example, music playback, recording, etc.

[0179] It should be understood that the steps in the above method embodiments can be completed by the integrated logic circuit in the hardware of the processor or the instructions in the form of software. The method steps disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware processor, or executed and completed by the combination of the hardware and software modules in the processor.

[0180] The present application also provides an electronic device, which may include: a memory, a processor, and a GPU, the three are coupled, and the GPU does not support OpenGL but supports Vulkan. Among them, the memory can be used to store computer programs; the processor can be used to call the computer programs in the memory so that the electronic device executes the methods executed by the electronic device in any one of the above embodiments.

[0181] The present application also provides a chip system, the chip system includes at least one processor, and is used to implement the functions involved in the electronic device in any one of the above embodiments.

[0182] In a possible design, the chip system further includes a memory, and the memory is used to save program instructions and data, and the memory is located inside or outside the processor.

[0183] The chip system can be composed of chips, or can include chips and other discrete devices.

[0184] Optionally, the processor in the chip system can be one or more. The processor can be implemented by hardware or by software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented by software, the processor can be a general-purpose processor, and is implemented by reading the software code stored in the memory.

[0185] Optionally, there may also be one or more memories in the chip system. The memory may be integrated with the processor or separately provided from the processor. The embodiments of the present application do not limit this. Exemplarily, the memory may be a non-transitory processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or may be separately provided on different chips. The embodiments of the present application do not specifically limit the type of the memory and the setting manner of the memory and the processor.

[0186] Exemplarily, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processing unit (CPU), a network processor (NP), a digital signal processing circuit (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0187] The present application also provides a computer program product, which includes: a computer program (which may also be referred to as code or instruction). When the computer program is run, it causes the computer to execute the method performed by the electronic device in any one of the above embodiments.

[0188] The present application also provides a computer-readable storage medium, which stores a computer program (which may also be referred to as code or instruction). When the computer program is run, it causes the computer to execute the method performed by the electronic device in any one of the above embodiments.

[0189] The various embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0190] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that incorporates one or more available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state disk (SSD)), etc.

[0191] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware with a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. The foregoing storage medium includes: various media that can store program codes such as ROM or random access memory RAM, magnetic disks, or optical discs.

[0192] In summary, the above descriptions are only embodiments of the technical solutions of the present application and are not used to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made in accordance with the disclosure of the present application shall be included within the protection scope of the present application.

[0193] In the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality of" means two or more than two.

[0194] The terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality" is two or more.

Claims

1. A rendering method, characterized in that, The method is applied to an electronic device including a GPU and a CPU, and the method includes: Generating a first instruction, the first instruction instructing to call a first interface to render a first image frame of an application; Calling the GPU to render the first image frame according to the first instruction; Generating a second instruction, the second instruction instructing to call a second interface to render a second image frame of the application; Calling the CPU to render the second image frame according to the second instruction.

2. The method according to claim 1, wherein The first interface can be implemented by the GPU, and the second interface cannot be implemented by the GPU.

3. The method according to claim 1 or 2, wherein The electronic device stores a whitelist, the whitelist includes the first interface and does not include the second interface; Or, the electronic device stores a blacklist, the blacklist includes the second interface and does not include the first interface.

4. The method according to any one of claims 1-3, characterized in that The GPU supports a first graphics rendering standard and does not support a second graphics rendering standard.

5. The method according to claim 4, characterized in that, The application is an application developed based on the second graphics rendering standard, and both the first interface and the second interface belong to the interfaces based on the second graphics rendering standard.

6. The method according to claim 4 or 5, characterized in that The first graphics rendering standard is Vulkan, and the second graphics rendering standard is OpenGL.

7. The method according to any one of claims 4 to 6, characterized in that The GPU includes the first interface and does not include a fourth interface, the fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function.

8. The method according to any one of claims 4 to 6, characterized in that The electronic device does not support converting the second interface to the fourth interface, the fourth interface is an interface based on the first graphics rendering standard, and the fourth interface and the second interface provide the same function.

9. The method according to any one of claims 4-8, wherein Calling the GPU to render the first image frame according to the first instruction specifically includes: according to the first instruction, calling a third interface of the GPU to render the first image frame, the third interface is an interface based on the first graphics rendering standard, and the third interface and the first interface provide the same function; Calling the CPU to render the second image frame according to the second instruction specifically includes: according to the second instruction, calling the CPU to implement the second interface to render the second image frame.

10. The method according to claim 9, wherein The electronic device includes Mesa, and Mesa includes Zink and Swrast; Calling the third interface of the GPU specifically includes: converting the first interface to the third interface through Zink, and calling the third interface of the GPU through Zink; Calling the CPU to implement the second interface specifically includes: calling the CPU through Swrast to implement the second interface.

11. The method according to claim 10, wherein Before calling the GPU to render the first image frame, the method further includes: generating a first context of the first image frame, the first context is in Zink format, and the first context is used for Zink to call the third interface of the GPU; Before invoking the CPU to implement the second interface, the method further includes: generating a second context for the second image frame, where the second context is in the Swrast format and is used by Swrast to invoke the CPU to implement the second interface.

12. The method according to claim 11, wherein The second image frame is an adjacent image frame after the first image frame; Generating the second context for the second image frame specifically includes: Generating a third context in the Zink format based on the first context and the image data of the second image frame; Converting the third context in the Zink format to the second context in the Swrast format.

13. The method according to claim 12, wherein The method further includes: Generating a third instruction that instructs to invoke a fifth interface to render a third image frame of the application; Generating a fourth context in the Swrast format based on the second context and the image data of the third image frame; Converting the fourth context in the Swrast format to a fifth context in the Zink format; Through the Zink, invoking the GPU to render the third image frame according to the fifth context.

14. The method according to any one of claims 10 - 13, characterized in that Before generating the first instruction, the method further includes: Loading the Zink and the Swrast; Initializing the rendering environments of the Zink and the Swrast.

15. The method according to any one of claims 1-14, characterized in that, The electronic device stores an application whitelist that includes the application.

16. The method according to any one of claims 1-15, wherein After rendering the first image frame, the method further includes: displaying the first image frame; After rendering the second image frame, the method further includes: displaying the second image frame.

17. An electronic device, characterized in that, Includes: A memory, one or more processors; The memory is coupled to the one or more processors, and the memory is used to store one or more programs. The one or more processors invoke the one or more programs to cause the electronic device to execute the method according to any one of claims 1-16.

18. A computer-readable storage medium, comprising instructions, characterized in that, When the instruction runs on the electronic device, the electronic device executes the method according to any one of claims 1-16.

19. A chip system, the chip system includes at least one processor and a memory. The memory is used to store program instructions and data, and the processor is used to invoke the program instructions and data to implement the method according to any one of claims 1-16.

Images