Multi-image processing unit core parallel image rendering method, processing unit and device
By allocating API calls for multiple frames of images to different image processing unit cores for rendering, the problem of low state synchronization efficiency in multi-core rendering is solved, and more efficient sequential output of image processing and rendering tasks is achieved.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- VERISILICON MICROELECTRONICS (SHANGHAI) CO LTD
- Filing Date
- 2024-12-18
- Publication Date
- 2026-06-25
AI Technical Summary
Existing multi-core rendering methods involve multiple state synchronization steps, resulting in low core efficiency and requiring additional core selection instructions, which increases the workload of the image processing unit.
By writing API calls for multiple frames of images to be rendered into preset M×N API call buffers, and distributing them to different image processing unit cores for rendering tasks, state synchronization is avoided, ensuring that each core independently completes the rendering of one frame of image.
It improves the efficiency of the image processing unit, reduces the state synchronization steps, balances the workload of each core, and ensures that the rendering tasks are output in the correct order.
Smart Images
Figure CN2024140389_25062026_PF_FP_ABST
Abstract
Description
Multi-image processing unit core parallel image rendering method, processing unit and device Technical Field
[0001] This application relates to the technical field of image rendering, and more specifically, provides a multi-image processing unit core parallel image rendering method, processing unit, and device. Background Technology
[0002] In existing multi-core rendering methods, each core collaborates to render the same frame. Therefore, to ensure the completeness and accuracy of the result, a large number of state synchronization steps are required, which significantly reduces the efficiency of multi-core processing. Furthermore, this multi-core rendering method requires continuous task allocation to each core. Consequently, additional core selection instructions need to be added to the driver's commands sent to the image processing unit to inform it which core to use for executing the instruction. This increases the workload of the image processing unit and further reduces rendering efficiency. Summary of the Invention
[0003] In view of this, this application aims to provide a multi-image processing unit core parallel image rendering method, processing unit and device to reduce state synchronization links, thereby improving core working efficiency.
[0004] In a first aspect, this application provides a parallel image rendering method using multiple image processing unit cores, applied to a processing unit. The method includes: acquiring all API (Application Programming Interface) calls of multiple frames of images to be rendered, and writing all API calls of each frame of the images to be rendered into different target API call caches in a preset M×N API call cache; wherein: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores among the N image processing unit cores; parsing all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the images to be rendered; sending all rendering tasks corresponding to each frame of the images to be rendered to each target image processing unit core, so that each target image processing unit core executes the rendering task corresponding to its own target image processing unit core, thereby realizing the rendering of multiple frames of the images to be rendered; wherein the rendering task corresponding to each target image processing unit core is: all rendering tasks obtained by parsing all API calls in the target API call cache corresponding to that target image processing unit core.
[0005] In this embodiment, since each API call buffer stores all API calls for at least one frame of image to be rendered, and an API call is only executed by its corresponding image processing unit core, the rendering task for all API calls of one frame of image to be rendered is completed by one image processing unit core, thus achieving the rendering of that frame of image to be rendered. This process does not require state synchronization between multiple image processing unit cores, thereby reducing the state synchronization step and improving the working efficiency of the image processing unit.
[0006] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, acquiring all API calls of multiple frames of images to be rendered, and writing all API calls of each frame of images to be rendered into different target API call buffers in M×N API call buffers, includes: acquiring all API calls of multiple frames of images to be rendered and the number of each frame of images to be rendered, and writing all API calls and the number of each frame of images to be rendered into different target API call buffers in M×N API call buffers; wherein, the number of the image to be rendered is used to be acquired by each target image processing unit core, so that after each target image processing unit core completes the rendering of the image to be rendered, the display buffer refresh API included in all API calls of the image to be rendered sequentially sends the rendered image to be displayed according to the number of each image to be rendered; the display buffer refresh APIs corresponding to different images to be rendered maintain different numbers of the images to be displayed.
[0007] In this embodiment, by writing the number of the image to be rendered into the API call cache, the image processing unit core can obtain the number of the image to be rendered, and then send the rendered image to be displayed according to the number of the image to be rendered. This prevents the displayed image from having problems such as frame skipping and rewinding due to incorrect order of the images to be rendered.
[0008] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, each of the image processing unit cores holds complete rendering resources required for rendering.
[0009] In this embodiment of the application, since each image processing unit core holds the complete rendering resources required for rendering, each image processing unit core can independently complete the rendering of a frame of image to be rendered.
[0010] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, all API calls of the image to be rendered in each frame are written into different target API call caches in a preset M×N API call cache, including: writing all API calls of the image to be rendered in each frame into different target API call caches in a preset M×N API call cache according to a preset arrangement order of the API call caches; wherein, in the M×N API call caches arranged in a preset arrangement order, N consecutive API call caches correspond to N image processing unit cores.
[0011] In this embodiment, since the N consecutive API call buffers correspond to N image processing unit cores respectively, when writing all API calls for multiple frames of images to be rendered, the multiple frames of images to be rendered can be evenly distributed to the N image processing unit cores to balance the workload of each image processing unit core and improve the working efficiency of the image processing unit cores.
[0012] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, parsing all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the image to be rendered includes: for each of the M API call caches corresponding to each image processing unit core, parsing all API calls in the M API call caches in a preset order, and the order in which the API calls in the M API call caches are parsed is the same as the order in which the API calls are written into the M API call caches.
[0013] In this embodiment, since the order in which the API calls in the M API call buffers are parsed is the same as the order in which the API calls are written into the M API call buffers, the image processing unit core can prioritize the rendering tasks of all API calls of the image to be rendered that were written first, thereby achieving the effect that the image to be rendered that was written first is output and displayed first.
[0014] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, after acquiring all API calls for multiple frames of images to be rendered, the method further includes: clearing the API calls for acquiring rendering resources corresponding to the core of the current target image processing unit that were previously stored in the newly added resource cache; wherein, the core of the current target image processing unit is the core of the target image processing unit corresponding to the current target API call cache that is currently writing API calls; the newly added resource cache is used to store API calls for acquiring rendering resources; all API calls in the cleared newly added resource cache are written into the current target API call cache; and the API calls for acquiring rendering resources in the images to be rendered corresponding to the current target API call cache are written into the newly added resource cache.
[0015] In this embodiment, after executing an API call to acquire rendering resources, the image processing unit core can obtain new rendering resources, and these resources can be reused thereafter. Therefore, for a target image processing unit core, as long as any of its corresponding API call caches contains an API call for acquiring rendering resources, it can acquire the new rendering resource. Thus, the API calls for acquiring rendering resources corresponding to the current target image processing unit core, previously stored in the new resource cache, can be cleared to avoid duplicate execution. Furthermore, writing the API calls for acquiring rendering resources from the image to be rendered corresponding to the current target API call cache into the new resource cache allows other image processing unit cores to also acquire API calls for acquiring rendering resources, thereby maintaining the integrity of the rendering resources.
[0016] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, after acquiring all API calls of multiple frames of images to be rendered, the method further includes: clearing all API calls in the target new resource buffer area corresponding to the current target image processing unit core; wherein, the current target image processing unit core is the target image processing unit core corresponding to the current target API call cache area where API calls are being written; the new resource cache area includes N, each new resource cache area corresponding to one image processing unit core, the new resource cache area being used to store API calls for acquiring rendering resources; writing all API calls in all new resource buffer areas corresponding to other image processing unit cores into the current target API call cache area; writing the API calls for acquiring rendering resources in the images to be rendered corresponding to the current target API call cache area into the target new resource buffer area.
[0017] In this embodiment, by setting a corresponding new resource cache area for each image processing unit core, all API calls for obtaining rendering resources that need to be written to the M API call cache areas corresponding to the same image processing unit core are located in the same new resource cache area. Therefore, during clearing, all API calls in the target new resource cache area corresponding to the current target image processing unit core can be directly cleared; during retrieval, all API calls in all new resource cache areas corresponding to all other image processing unit cores can be retrieved. This reduces the probability of errors during clearing and retrieval.
[0018] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, each API call cache stores all API calls for one frame of image to be rendered at a time.
[0019] Secondly, this application provides a parallel image rendering method for multiple image processing unit cores, applied to any one of the image processing unit cores. The method includes: receiving and executing rendering tasks sent by the processing unit to render an image to be rendered; wherein the rendering tasks are all rendering tasks obtained after parsing API calls in the target API call cache corresponding to the image processing unit core; wherein the target API call cache is an API call cache containing all API calls of at least one frame of the image to be rendered from a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
[0020] In this embodiment, a single image processing unit core executes API calls from its corresponding target API call cache, thereby rendering a single frame of image to be rendered. This process eliminates the need for state synchronization between multiple image processing unit cores, reducing the need for state synchronization and thus improving the efficiency of the image processing unit.
[0021] In conjunction with the technical solution provided in the second aspect above, in some possible implementations, the method further includes: obtaining the number of the image to be rendered; after rendering the image to be rendered is completed, executing the display buffer refresh API in the API call in the target API call cache, so as to send the rendered images to be rendered sequentially according to the number of the images to be rendered; the display buffer refresh API maintains different numbers of the images to be displayed for different images to be rendered.
[0022] Thirdly, this application provides a multi-image processing unit core parallel image rendering method, comprising: a processing unit acquiring all API calls of multiple frames of images to be rendered, and writing all API calls of each frame of the images to be rendered into different target API call caches in a preset M×N API call cache; wherein: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in the N image processing unit cores; the processing unit parses all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the images to be rendered; the processing unit writes all API calls corresponding to each frame of the images to be rendered into a target API call cache. Rendering tasks are sent to each target image processing unit core; each target image processing unit core receives and executes the rendering task sent by the processing unit to render the image to be rendered; wherein, the rendering task is all rendering tasks obtained after parsing API calls in the target API call cache corresponding to the image processing unit core; wherein, the target API call cache is: an API call cache containing all API calls of at least one frame of the image to be rendered written in a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
[0023] Fourthly, this application provides a processing unit for performing the method described in the first aspect and / or in combination with any possible implementation of the first aspect.
[0024] Fifthly, this application provides an image processing unit for performing the method described in the second aspect and / or in combination with any possible implementation of the second aspect.
[0025] In a sixth aspect, this application provides an electronic device, comprising: a processing unit and an image processing unit, the processing unit and the image processing unit being connected; the processing unit being configured to perform the method described in the first aspect and / or in combination with any possible embodiment of the first aspect; the image processing unit being configured to perform the method described in the second aspect and / or in combination with any possible embodiment of the second aspect. Attached Figure Description
[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0027] Figure 1 is a flowchart illustrating the first multi-image processing unit core parallel image rendering method provided in the embodiments of this application;
[0028] Figure 2 is a schematic diagram of an image processing unit core corresponding to two API scheduling buffers provided in an embodiment of this application;
[0029] Figure 3 is a schematic diagram of an image processing unit core corresponding to two API scheduling buffers and a newly added resource cache area provided in an embodiment of this application;
[0030] Figure 4 is a schematic diagram of an image rendering system architecture provided in an embodiment of this application;
[0031] Figure 5 is a schematic diagram of the order in which each frame of the image to be rendered is written into the API scheduler according to an embodiment of this application;
[0032] Figure 6 is a schematic diagram of a process for writing API calls to the API call cache according to an embodiment of this application;
[0033] Figure 7 is a schematic diagram of a process for executing API calls in an API call cache according to an embodiment of this application;
[0034] Figure 8 is a flowchart illustrating the second type of multi-image processing unit core parallel image rendering method provided in the embodiments of this application;
[0035] Figure 9 is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0036] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.
[0037] Please refer to Figure 1, which is a flowchart illustrating the first multi-image processing unit core parallel image rendering method according to an embodiment of this application. This multi-image processing unit core parallel image rendering method is applied to the processing unit, and the steps it includes will be described below with reference to Figure 1.
[0038] S110: Obtain all API calls for multiple frames of images to be rendered, and write all API calls for each frame of images to be rendered into different target API call buffers in the preset M×N API call buffers.
[0039] Where N is a positive integer greater than 1, M is a positive integer greater than 1, every M API call caches correspond to one image processing unit core, and at least two target API call caches correspond to different target image processing unit cores among the N image processing unit cores. An image processing unit core refers to the smallest working unit in an image processing unit that can independently and completely perform image rendering operations.
[0040] The processing unit can be a data processing core of a CPU (Central Processing Unit), AI (Artificial Intelligence), NPU (Neural Network Processing Unit), ISP (Image Signal Processor), DPU (Display Processing Unit), VPU (Video Processing Unit), or DSP (Digital Signal Processor), or it can be a processor chip used in scenarios involving large-scale data computation. The above are merely examples and should not be construed as limiting this application.
[0041] The image processing unit can be any type of GPU (Graphics Processing Unit), or NPU, ISP, DPU, VPU, etc. The above are merely examples and should not be construed as limiting this application.
[0042] When the image processing unit is a GPU, the image processing unit core is the GPU core.
[0043] All API calls to the image to be rendered can be obtained from third-party electronic devices, or they can be sent by the currently running application.
[0044] API calls refer to the functions, parameters, and output types corresponding to the API interfaces. All API calls to the image to be rendered are written to the target API call buffer; that is, the function, parameters, and output types corresponding to each API call are written to this API call buffer.
[0045] In one implementation, the preset M×N API call caches can be pre-configured, or they can be created by an application that needs to use rendering functionality.
[0046] In order for each image processing unit core to complete the rendering operation of a frame of image to be rendered, optionally, each image processing unit core holds the complete rendering resources required for rendering.
[0047] The rendering resources can include scene packages, component packages, texture resources, shader resources, and material resources. The specific type of rendering resources can be configured for the core of the image processing unit according to actual needs, and there are no restrictions on its specific type here.
[0048] In one implementation, an API call buffer can hold all API calls for multiple frames of images to be rendered at once. After all API calls for the multiple frames of images to be rendered have been written, S120 and S130 are executed.
[0049] Optionally, each API call buffer can also store all API calls for one frame of the image to be rendered at a time.
[0050] In one implementation, before writing all API calls for the image to be rendered into the API call buffer, it is necessary to delete all previously executed API calls that have been written into the API call buffer. Then, all API calls for the image to be rendered are written.
[0051] Optionally, the image processing unit may delete all API calls in the target API call cache after executing all API calls in the target API call cache.
[0052] Alternatively, all API calls in the API call buffer can be deleted when all API calls are ready to be written to the image to be rendered.
[0053] There are three possible implementation methods for writing all API calls of each frame of the image to be rendered into different target API call buffers in the preset M×N API call buffers.
[0054] In the first implementation, the specific method of writing all API calls of each frame of the image to be rendered into different target API call buffers in the preset M×N API call buffers can be as follows: based on the idle rate of the M API call buffers corresponding to each image processing unit core (that is, the ratio of the API call buffer waiting to be written to M), all API calls of the image to be rendered are preferentially written to the API call buffer corresponding to the image processing unit core with a high idle rate.
[0055] If all image processing unit cores have the same idle rate, then all API calls to the image to be rendered can be randomly written to the waiting API call buffer. Alternatively, the next API call buffer to be written to can be determined according to the pre-arranged writing order of the API call buffers.
[0056] For example, if there are two image processing unit cores, image processing unit core 1 and image processing unit core 2, and image processing unit core 1 corresponds to API call cache 11, API call cache 12 and API call cache 13, and image processing unit core 2 corresponds to API call cache 21, API call cache 22 and API call cache 23.
[0057] If image processing unit core 1 is currently executing API calls in API call buffer 11, and image processing unit core 2 is currently executing API calls in API call buffer 21, and API call buffer 12 has already completed writing all API calls for the image to be rendered, then the API call buffers currently waiting to be written are API call buffer 13, API call buffer 22, and API call buffer 23. Therefore, image processing unit core 2 has a higher idle rate (2 / 3), and thus, priority is given to writing all API calls for the next frame of the image to be rendered to the corresponding API call buffer (API call buffer 22 or API call buffer 23).
[0058] If image processing unit core 1 is currently executing API calls in API call cache 11, and image processing unit core 2 is currently executing API calls in API call cache 21, and the API call caches currently waiting to be written to are API call cache 12, API call cache 13, API call cache 22, and API call cache 23, then it is possible to randomly select one of these four API call caches (API call cache 12, API call cache 13, API call cache 22, and API call cache 23) to write all the API calls for the next frame of the image to be rendered.
[0059] Alternatively, if the pre-configured write order of the API call buffers is API call buffer 11, API call buffer 21, API call buffer 12, API call buffer 22, API call buffer 13, and API call buffer 23, then all API calls for the next frame of the image to be rendered will be written to API call buffer 12.
[0060] Alternatively, if the pre-set order is Image Processing Unit Core 1, Image Processing Unit Core 2, then all API calls to be written to the API call buffer 12 or API call buffer 13 for the next frame of the image to be rendered are determined.
[0061] The examples provided are for illustrative purposes only and should not be construed as limiting the scope of this application.
[0062] In the second implementation, writing all API calls of each frame of the image to be rendered into different target API call caches in the preset M×N API call caches can also be done by: based on the workload being executed by each image processing unit core, prioritizing writing all API calls of the image to be rendered into the API call cache corresponding to the image processing unit core with a low workload.
[0063] The workload being performed by the image processing unit core can be the total number of draw calls for the frames being processed on the image processing unit core, or it can be the total number of primitives and vertices for the frames being processed on the image processing unit core.
[0064] A draw call is a type of graphics API call and is the most crucial call in rendering. It directly drives the image processing unit to perform rendering and can balance the workload of the image processing unit at a finer granularity.
[0065] Primitives can be considered the smallest unit of rendering tasks for the image processing unit (EPU). A draw call instructs the EPU to execute rendering tasks for one or more primitives. Vertices are a component of primitives and can also reflect the task status of the EPU.
[0066] In the third implementation, writing all API calls of each frame of the image to be rendered into different target API call buffers in the preset M×N API call buffers can also be done by sequentially writing all API calls of each frame of the image to be rendered into different target API call buffers in the preset M×N API call buffers according to the preset arrangement order of the API call buffers. In the M×N API call buffers arranged in the preset order, N consecutive API call buffers correspond to N image processing unit cores.
[0067] Since the N consecutive API call buffers correspond to N image processing unit cores respectively, when writing all API calls for multiple frames of images to be rendered, the multiple frames of images to be rendered can be evenly distributed to the N image processing unit cores to balance the workload of each image processing unit core and improve the working efficiency of the image processing unit cores.
[0068] For easier understanding, please refer to Figure 2. As shown in Figure 2, taking M=2 as an example, there are a total of 2×N (hereinafter referred to as 2N) API call buffers (in order from the 1st API call buffer to the 2Nth API call buffer). Each image processing unit core corresponds to 2 API call buffers. Since N consecutive API call buffers correspond to N image processing unit cores, there is a gap of N-1 call buffers between two API call buffers corresponding to the same image processing unit core. That is, the order of the two API call buffers corresponding to the i-th image processing unit core in the 2N API call buffers is the i-th API call buffer and the (i+N)-th API call buffer, where i is a positive integer greater than 0 and less than or equal to N.
[0069] Taking the example of writing all API calls for one frame of the image to be rendered to the API call buffer at a time, the process begins by writing all API calls for the first frame of the image to be rendered to the first API call buffer; then, it continues to the second API call buffer, writing all API calls for the second frame of the image to be rendered, and so on, until all API calls for the 2Nth frame of the image to be rendered are written to the 2Nth API call buffer. Then, all API calls for the (2N+1)th frame of the image to be rendered are written to the first API call buffer. This example is for illustrative purposes only and should not be construed as a limitation of this application.
[0070] Optionally, in the third implementation, for each image processing unit core, the specific method for parsing all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the image to be rendered can be: for each of the M API call caches corresponding to each image processing unit core, parse all API calls in the M API call caches in a preset order, and the order in which the API calls in the M API call caches are parsed is the same as the order in which the API calls are written into the M API call caches.
[0071] Since the order in which the API calls in the M API call buffers are parsed is the same as the order in which the API calls are written into the M API call buffers, the image processing unit core can prioritize executing all API calls of the images to be rendered that were written first, thus achieving the effect that the images to be rendered that were written first are output and displayed first.
[0072] In this implementation, the writing order of the M API call buffers corresponding to the i-th image processing unit core is as follows: the i-th API call buffer, the (i+N)-th API call buffer, the (i+2N)-th API call buffer, ..., the (i+(M-1)N)-th API call buffer, and this order is repeated cyclically, where i is a positive integer greater than 0 and less than or equal to N. Therefore, for the i-th image processing unit core, the order in which it executes API calls in the corresponding M API call buffers is also: the i-th API call buffer, the (i+N)-th API call buffer, the (i+2N)-th API call buffer, ..., the (i+(M-1)N)-th API call buffer, and this order is repeated cyclically. This example is for illustrative purposes only and should not be construed as a limitation of this application.
[0073] Optionally, in the third implementation, after acquiring all API calls for multiple frames of images to be rendered, the API calls for acquiring rendering resources corresponding to the current target image processing unit core, previously stored in the newly added resource cache, can be cleared. Here, the current target image processing unit core is the target image processing unit core corresponding to the current target API call cache where API calls are being written; the newly added resource cache is used to store API calls for acquiring rendering resources. Then, all API calls in the cleared newly added resource cache are written to the current target API call cache. Afterward, the API calls for acquiring rendering resources in the images to be rendered corresponding to the current target API call cache are written to the newly added resource cache.
[0074] After executing the API call to acquire rendering resources, the image processing unit (IPU) core can obtain new rendering resources, and these resources can be reused. Therefore, for a target IPU core, as long as any of its corresponding API call caches contains an API call for acquiring rendering resources, it can acquire the new rendering resource. Thus, the previously stored API calls for acquiring rendering resources for the current target IPU core in the new resource cache can be cleared to avoid duplicate execution. Furthermore, writing the API calls for acquiring rendering resources from the image to be rendered corresponding to the current target's API call cache into the new resource cache allows other IPU cores to also acquire these API calls, thereby maintaining the integrity of the rendering resources.
[0075] To facilitate understanding, we will use the example shown in Figure 2 for illustration.
[0076] When writing all API calls for the i-th frame of the image to be rendered to the i-th API call buffer (if it is the first frame, there will be no other API calls previously, so the clearing step can be skipped), all API calls written to the new resource buffer by other API call buffers corresponding to the i-th image processing unit core during API call writing are deleted. Then, all remaining API calls in the new resource buffer are written to the i-th API call buffer. After that, the API calls for obtaining rendering resources for the i-th frame of the image to be rendered are written to the new resource buffer (if there are no API calls for obtaining rendering resources for the i-th frame of the image to be rendered, this writing step is not performed).
[0077] Next, when writing all API calls for the (i+1)th frame of the image to be rendered to the (i+1)th API call buffer, the API calls written to the new resource buffer in the other API call buffers corresponding to the (i+1)th image processing unit core are deleted. Then, all remaining API calls in the new resource buffer are written to the (i+1)th API call buffer. Then, the API calls for obtaining rendering resources for the (i+1)th frame of the image to be rendered are written to the new resource buffer, and the above steps are repeated.
[0078] Optionally, in the third implementation, after acquiring all API calls for multiple frames of images to be rendered, the process can also be as follows: clear all API calls in the target new resource buffer area corresponding to the current target image processing unit core; wherein, the current target image processing unit core is the target image processing unit core corresponding to the current target API call cache area where API calls are being written; the new resource cache area includes N areas, each corresponding to one image processing unit core, and the new resource cache area is used to store API calls for acquiring rendering resources. Then, all API calls in all new resource buffer areas corresponding to other image processing unit cores are written into the current target API call cache area. Finally, the API calls for acquiring rendering resources in the images to be rendered corresponding to the current target API call cache area are written into the target new resource buffer area.
[0079] By setting up a corresponding new resource cache area for each image processing unit core, all API calls needed to retrieve rendering resources in the M API call cache areas corresponding to the same image processing unit core are located within the same new resource cache area. Therefore, during clearing, all API calls in the target new resource cache area corresponding to the current target image processing unit core can be cleared directly; during retrieval, all API calls in all new resource cache areas corresponding to all other image processing unit cores can be retrieved. This reduces the probability of errors during clearing and retrieval.
[0080] For ease of understanding, the example shown in Figure 3 will be used. Here, the i-th image processing unit core corresponds to the i-th newly added resource cache area.
[0081] When writing all API calls for the i-th frame of the image to be rendered to the i-th API call buffer (if it is the first frame of the image, there will be no other API calls before, so the clearing step can be skipped), all API calls in the i-th newly added resource buffer area corresponding to the i-th image processing unit core are deleted. Then, all API calls in the other newly added resource buffer areas (N-1 newly added resource buffer areas other than the i-th newly added resource buffer area) are written to the i-th API call buffer. After that, the API calls for obtaining rendering resources for the i-th frame of the image to be rendered are written to the i-th newly added resource buffer area (if there are no API calls for obtaining rendering resources for the i-th frame of the image to be rendered, this writing step is not performed).
[0082] Next, when writing all API calls for the (i+1)th frame of the image to be rendered to the (i+1)th API call buffer, all API calls in the (i+1)th newly added resource buffer corresponding to the (i+1)th image processing unit core are deleted. Then, all API calls in the other newly added resource buffers (N-1 newly added resource buffers excluding the (i+1)th newly added resource buffer) are written into the (i+1)th API call buffer. Then, the API calls for obtaining rendering resources for the (i+1)th frame of the image to be rendered are written into the (i+1)th newly added resource buffer, and the above steps are repeated.
[0083] In one implementation, the specific method for obtaining all API calls of multiple frames of images to be rendered and writing all API calls of each frame of images to be rendered into different target API call caches in M×N API call caches can be as follows: First, obtain all API calls of multiple frames of images to be rendered and the number of each frame of images to be rendered, and write all API calls and the number of each frame of images to be rendered into different target API call caches in M×N API call caches.
[0084] The number of the image to be rendered is obtained by the core of each target image processing unit. After the core of each target image processing unit completes the rendering of the image to be rendered, the display buffer refresh API, which is included in all API calls of the image to be rendered, transmits the rendered image to the display buffer in sequence according to the number of each image to be rendered, thereby updating the content displayed on the screen and other display devices. The number of the image to be rendered is different in the display buffer refresh API corresponding to different images to be rendered.
[0085] Depending on the graphics standard library used by the platform, the display buffer refresh API can be different APIs such as glXSwapBuffers, eglSwapBuffers, and vkQueuePresentKHR. No specific restrictions are placed on the specific type of the display buffer refresh API here.
[0086] Since the display buffer refresh API maintains the same display image number as the corresponding image number to be rendered, and different images to be rendered must have different numbers, the display buffer refresh API maintains different numbers for different images to be rendered.
[0087] Optionally, during the display submission process, a global variable can be maintained, representing the number of the image to be submitted. Therefore, if the number maintained in the display buffer refresh API is the same as this global variable, the image to be rendered corresponding to that display buffer refresh API is submitted. After submitting one frame of the image to be rendered, this global variable is incremented by one.
[0088] By writing the ID of the image to be rendered into the API call cache, the image processing unit core can obtain the ID of the image to be rendered, and then send the rendered image to be displayed according to the ID. This prevents the displayed video from having problems such as frame skipping or rewinding due to incorrect order of the images to be rendered.
[0089] Optionally, after writing all API calls for a frame of image to be rendered into the target API call buffer, the image number f is written into the target API call buffer. When the image processing unit core executes all API calls in the target API call buffer, it can obtain the number f. After the image to be rendered is completed, the rendered image to be displayed and the number f are sent to the refresh display buffer in the user-mode driver. The user-mode driver maintains a global variable F (which is the number of the image to be displayed). If the number f of the rendered image to be displayed equals F, the image to be displayed is sent to the display buffer, and the value of F is incremented by 1. If they are not equal, the process waits until they are equal. This ensures that the final display order is the same as the writing order of the images to be rendered.
[0090] S120: Parse all API calls in the API call buffer for each target to obtain all rendering tasks corresponding to each frame of the image to be rendered.
[0091] Here, the specific operations for the rendering task obtained by parsing the API call can be executed by the image processing unit.
[0092] Optionally, there can be N image processing unit driver threads, with each of the N image processing unit driver threads corresponding one-to-one with one of the N image processing unit cores. Correspondingly, when parsing all API calls in each target API call cache, each image processing unit driver thread parses all API calls in its corresponding API call cache. The API call cache corresponding to each image processing unit driver thread is: the API call cache corresponding to the image processing unit core of that image processing unit driver thread.
[0093] In one implementation, before parsing all API calls in the target API call cache, it is necessary to first determine that all API calls in the target API call cache have been written.
[0094] Optionally, the specific method for determining that all API calls in the target API call cache have been written can be as follows: For each target API call cache, after all API calls have been written in that target API call cache, a notification indicating that the writing is complete is sent. In response to this notification, all API calls recorded in the target API call cache are retrieved and parsed to obtain the corresponding rendering task.
[0095] The notification information can be interrupt signals, execution commands, etc., and there are no restrictions on its specific type here.
[0096] Optionally, when an image processing unit core corresponds to multiple API call caches, the order in which the received notification information is received is recorded, and then the API calls in the target API call cache are parsed sequentially based on this order.
[0097] In one implementation, each API call buffer may maintain a flag bit, the value of which indicates one of the following: execution (or parsing) or writing is allowed. In this case, for each target API call buffer, after all API calls have been written to that buffer, the flag bit is updated to a first value indicating the existence of API calls to be executed (i.e., execution is allowed). After all API calls in that target API call buffer have been executed, the flag bit is updated to a second value indicating that writing API calls is allowed.
[0098] Optionally, in this implementation, before writing API calls to the API call buffer, the value of a flag bit needs to be checked. If the flag bit value is the second value indicating that API calls are allowed to be written, then all API calls for the image to be rendered can be written to the API call buffer. If the flag bit value is the first value indicating that there are API calls to be executed, then wait until the flag bit value changes to the second value.
[0099] Similarly, before executing the target API call buffer, the value of the flag needs to be checked. If the flag value is the first value, indicating that there is an API call to be executed, then the API call in the target API call buffer is executed. If the flag value is the second value, indicating that writing to the API call is allowed, then wait until the flag value changes to the first value.
[0100] In one implementation, after writing all the API calls for a frame of image to be rendered to the target API call buffer, a first value representing the API call to be executed is added to the target API call buffer. This first value can be a field or a piece of information.
[0101] After all API calls in the API call buffer have been executed, a second value representing the API calls allowed to be written to the API call buffer is added to the buffer. This second value can be a field or a piece of information.
[0102] S130: Send all rendering tasks corresponding to each frame of the image to be rendered to each target image processing unit core, so that each target image processing unit core executes the rendering task corresponding to its own target image processing unit core, thereby realizing the rendering of the multiple frames of the image to be rendered.
[0103] The rendering task corresponding to each target image processing unit core is: all rendering tasks obtained by parsing all API calls in the target API call cache area corresponding to the target image processing unit core.
[0104] In one implementation, the image rendering method described above can be executed by an API cache scheduler. Typically, the graphics rendering software stack workflow involves the application (game software, video software, office software, etc.) that needs to perform rendering calling standard graphics APIs, entering the user-mode image processing unit driver (or GPU driver if the image processing unit is a GPU), translating these APIs into instructions for the graphics card (i.e., parsing the API calls to obtain the rendering task), and sending them to the image processing unit via the kernel-mode image processing unit driver for execution. In this mode, the calling and execution of standard graphics APIs can be considered synchronous. This solution adds a new API cache scheduler layer between the application and the user-mode driver, as shown in Figure 4. Figure 4 illustrates this using two API call cache areas corresponding to each image processing unit core as an example. It should be noted that in practical applications, the number of API call cache areas corresponding to each image processing unit core is not limited to two; it can also be three or more.
[0105] When an application calls a standard graphics API, it does not enter the user-mode driver but instead enters the API cache scheduler, which returns immediately after execution. The application can create 2*N API call buffers to record API calls. These buffers are used sequentially. Each time the application calls a graphics API that refreshes the display buffer (such as the standard API function eglSwapBuffers, etc.) (i.e., all API calls for the previous frame of the image to be rendered are written, and the application switches to the next frame), it switches to the next API call buffer (i.e., after the application writes all API calls for one frame of the image to be rendered to one API call buffer, it switches to the next API call buffer to continue writing API calls for the next frame). Thus, each API call buffer stores all API calls for each frame of the image to be rendered, as shown in Figure 5.
[0106] The API cache scheduler starts N threads while recording API calls to execute them. Each thread corresponds to an image processing unit core, which in turn calls the corresponding API call cache to execute the API calls in that core. For clarity, thread Tn will be used to represent the thread executing the call corresponding to the nth image processing unit core, such as thread T1 corresponding to the 1st image processing unit core, and so on. During execution, Tn will only loop through the nth and (n+Nth)th API call caches, executing API calls in one cache until all calls in the cache are completed, moving on to the next cache for execution, as shown in Figure 2.
[0107] Each API call buffer stores a flag to indicate the usage status of that API call buffer. The value of this flag can have two meanings: allow logging or allow execution.
[0108] As shown in Figure 6, when the application calls the graphics API and enters the API cache scheduler to record all API calls for the frame to be rendered, it first checks the flag bit of the current API call buffer i to be written. If it is the second value indicating that recording is allowed, then all API calls for the image to be rendered are written into that API call buffer. After all API calls for the image to be rendered have been written, recording stops, and the flag bit value is modified to the first value indicating that execution is allowed. The flag bit of the next API call buffer is queried. If the flag bit value is the first value indicating that execution is allowed, then a spin wait is entered until it is set to the second value indicating that recording is allowed.
[0109] As shown in Figure 7, when each execution thread is about to enter the cache for execution, it first checks this flag. If it is in the state of allowed execution, it enters the API call cache and executes API calls in sequence. After execution, the cache flag is set to the second value of allowed recording, and the next API cache flag to be executed is queried. This process is repeated. If it is in the state of allowed recording, it enters a spin wait until it is set to the state of allowed execution.
[0110] Because it is necessary to ensure that the rendering work of each image processing unit core remains independent and to completely eliminate the synchronization dependency between image processing unit cores, each execution thread needs to create its own independent rendering context. Each thread (that is, each image processing unit core) holds its own set of rendering resources (texture resources, shader resources, etc.).
[0111] At this point, each image processing unit core will almost simultaneously complete the rendering of a frame and wait to be displayed. A mechanism is needed to ensure the correct frame order for refreshing the display buffer. Therefore, after the application's main thread has recorded all API calls for a frame (the API call buffer has completed writing all API calls for a frame of images to be rendered), the number of the currently rendered image, denoted as f, needs to be recorded in the current API buffer. During execution, f is passed to the relevant function in the user-mode driver for refreshing the display buffer via the execution thread. A global variable F is created and maintained in the user-mode driver, representing the number of the image to be displayed at this moment. When each execution thread enters the display buffer to refresh the API, it first checks the number f of the image to be displayed (the value of f differs for different threads). If f equals F, it enters the display buffer refresh function, displays its own image, and increments the value of F by 1; if they are not equal, it spins and waits until they are equal. This ensures that the final display order is the same as the order issued by the application.
[0112] Since each execution thread independently holds its own set of rendering resources and does not interfere with each other, to prevent resource shortages for a particular core due to frame dependencies, N new resource buffer areas are added. Each new resource buffer area corresponds to an image processing unit core, and these buffer areas store API calls used to obtain rendering resources. When writing API calls to the API call buffer area, all API calls in the target new resource buffer area corresponding to the current target image processing unit core are cleared; all API calls in all new resource buffer areas corresponding to other image processing unit cores are written to the current target API call buffer area; and API calls for obtaining rendering resources from the image to be rendered corresponding to the current target API call buffer area are written to the target new resource buffer area.
[0113] Based on the same technical concept, this application also provides a parallel image rendering method with multiple image processing unit cores, which is applied to any one of the image processing unit cores in the image processing unit.
[0114] The core parallel image rendering method of the multi-image processing unit includes: receiving and executing rendering tasks sent by the processing unit to render the image to be rendered.
[0115] Among them, the rendering tasks are all the rendering tasks obtained after parsing the API calls in the target API call cache area corresponding to the core of the image processing unit.
[0116] The target API call cache is defined as follows: among the preset M×N API call caches, there is an API call cache containing all API calls of at least one frame of image to be rendered; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
[0117] The specific method for sending the image to be rendered has been clearly described above, and will not be repeated here for the sake of brevity.
[0118] The specific processing method of the image rendering method executed by the core of the image processing unit has been clearly described above, and will not be repeated here for the sake of brevity.
[0119] In one implementation, the core parallel image rendering method of the multi-image processing unit may further include: obtaining the number of the image to be rendered; and after rendering the image to be rendered is completed, executing the display buffer refresh API in the API call in the target API call buffer to sequentially send the rendered images to be displayed according to their numbers. The display buffer refresh API maintains different numbers of the images to be displayed for different images to be rendered.
[0120] For example, if three frames of images have been rendered and are numbered 1001, 1002, and 1003, the display buffer refresh API corresponding to image number 1001 should be executed first to display that image. Then, the display buffer refresh API corresponding to image number 1002 should be executed to display that image. Finally, the display buffer refresh API corresponding to image number 1003 should be executed to display that image.
[0121] Optionally, during the display submission process, a global variable can be maintained, representing the number of the image to be submitted. Therefore, if the number maintained in the display buffer refresh API is the same as this global variable, the image to be rendered corresponding to that display buffer refresh API is submitted. After submitting one frame of the image to be rendered, this global variable is incremented by one.
[0122] The process involves obtaining the number of the image to be rendered. After rendering the image, the display buffer refresh API in the API call in the target API call buffer is executed to send the rendered images to be displayed sequentially according to their numbers. The specific implementation of this process has been clearly described above and will not be repeated here for brevity.
[0123] Based on the same technical concept, this application also provides a multi-image processing unit core parallel image rendering method, as shown in Figure 8. The steps involved will be described below with reference to Figure 8.
[0124] S210: The processing unit obtains all API calls of multiple frames of images to be rendered, and writes all API calls of each frame of images to be rendered into different target API call buffers in the preset M×N API call buffers respectively.
[0125] Where: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
[0126] S220: The processing unit parses all API calls in the target API call buffer for each frame to obtain all rendering tasks corresponding to each frame of the image to be rendered.
[0127] S230: The processing unit sends all rendering tasks corresponding to each frame of the image to be rendered to the core of each target image processing unit.
[0128] S240: Each target image processing unit core receives and executes the rendering task sent by the processing unit to realize the rendering of the image to be rendered.
[0129] Among them, the rendering tasks are all the rendering tasks obtained after parsing the API calls in the target API call cache area corresponding to the core of the image processing unit.
[0130] The target API call cache is: an API call cache containing all API calls of at least one frame of image to be rendered, which are written in the preset M×N API call caches; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two target API call caches correspond to different target image processing unit cores in the N image processing unit cores.
[0131] The specific implementation of S210-S240 shown in Figure 8 can be referred to the aforementioned S110-S130, as well as the aforementioned multi-image processing unit core parallel image rendering method applied to any one of the image processing unit cores in the image processing unit. For the sake of brevity, it will not be elaborated here.
[0132] Based on the same technical concept, this application also provides a processing unit for executing the aforementioned multi-image processing unit core parallel image rendering method.
[0133] For example, the processing unit can be used to obtain all API calls for multiple frames of images to be rendered, and write all API calls for each frame of the images to be rendered into different target API call caches in a preset M×N API call cache; where: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in the N image processing unit cores; parse all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the images to be rendered; send all rendering tasks corresponding to each frame of the images to be rendered to each target image processing unit core, so that each target image processing unit core executes the rendering task corresponding to its own target image processing unit core, thereby realizing the rendering of multiple frames of the images to be rendered; wherein, the rendering task corresponding to each target image processing unit core is: all rendering tasks obtained by parsing all API calls in the target API call cache corresponding to that target image processing unit core.
[0134] The specific execution logic of the processing unit and its specific implementation method have been clearly described above, and will not be repeated here for the sake of brevity.
[0135] Based on the same technical concept, this application also provides an image processing unit for executing the aforementioned multi-image processing unit core parallel image rendering method.
[0136] For example, each layer processing unit core in the image processing unit is used to receive and execute rendering tasks sent by the processing unit to render the image to be rendered; wherein, the rendering task is all rendering tasks obtained after parsing API calls in the target API call cache corresponding to the image processing unit core; wherein, the target API call cache is: an API call cache in which all API calls of at least one frame of the image to be rendered are written in a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in the N image processing unit cores.
[0137] The specific execution logic of the image processing unit and its specific implementation method have been clearly described above, and will not be repeated here for the sake of brevity.
[0138] Based on the same technical concept, this application also provides an electronic device, as shown in FIG9. The electronic device 100 includes a processing unit 110 and an image processing unit 120, wherein the processing unit 110 and the image processing unit 120 are connected.
[0139] Processing unit 110 is used to execute the image rendering method and its various implementations provided in this embodiment. For example, processing unit 110 is used to execute all API calls to obtain multiple frames of images to be rendered, and write all API calls of each frame of the images to be rendered into different target API call caches in a preset M×N API call cache; where: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in the N image processing unit cores; parse all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the images to be rendered; send all rendering tasks corresponding to each frame of the images to be rendered to each target image processing unit core, so that each target image processing unit core executes the rendering task corresponding to its own target image processing unit core, so as to realize the rendering of multiple frames of the images to be rendered; wherein, the rendering task corresponding to each target image processing unit core is: all rendering tasks obtained by parsing all API calls in the target API call cache corresponding to the target image processing unit core.
[0140] The processing unit 110 can be a data processing core of CPU, AI, NPU, ISP, DPU, VPU, DSP, etc., and its specific type is not limited here.
[0141] Image processing unit 120 is used to execute the image rendering method described above for any one of the image processing unit cores. For example, each core in image processing unit 120 is used to execute API calls in the target API call cache corresponding to the image processing unit core in response to a notification sent by processing unit 110, thereby rendering the image to be rendered; or, accessing the flag value of the target API call cache corresponding to the image processing unit core, and when the flag value is a first value indicating the existence of an API call to be executed, executing the API call in the corresponding target API call cache to render the image to be rendered; wherein, the target API call cache is: an API call cache in which all API calls of at least one frame of the image to be rendered are written in a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
[0142] The image processing unit 120 can be any type of GPU (Graphics Processing Unit), or NPU, ISP, DPU, VPU, etc.
Claims
1. A multi-image processing unit core parallel image rendering method, characterized in that, Applied to a processing unit, the method includes: All API calls of multiple frames of images to be rendered are obtained, and all API calls of each frame of the images to be rendered are written into different target API call caches in M×N preset API call caches; where: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in N image processing unit cores; Analyze all API calls in the API call buffer for each target to obtain all rendering tasks corresponding to each frame of the image to be rendered. All rendering tasks corresponding to each frame of the image to be rendered are sent to each target image processing unit core, so that each target image processing unit core executes the rendering task corresponding to its own target image processing unit core, thereby realizing the rendering of multiple frames of the image to be rendered; wherein, the rendering task corresponding to each target image processing unit core is: all rendering tasks obtained by parsing all API calls in the target API call cache area corresponding to the target image processing unit core.
2. The method according to claim 1, characterized in that, Retrieve all API calls for multiple frames of images to be rendered, and write all API calls for each frame of the images to be rendered into different target API call buffers in M×N API call buffers, including: Obtain all API calls for multiple frames of images to be rendered and the number of each frame of the image to be rendered, and write all API calls and the numbers of each frame of the image to be rendered into different target API call caches in M×N API call caches respectively; The number of the image to be rendered is obtained by each of the target image processing units. After each target image processing unit completes the rendering of the image to be rendered, the display buffer refresh API, which is included in all API calls of the image to be rendered, sequentially sends the rendered image to be displayed according to the number of each image to be rendered. The display buffer refresh API maintains different image numbers for different images to be rendered.
3. The method according to claim 1, characterized in that, Each of the image processing unit cores holds the complete rendering resources required for rendering.
4. The method according to claim 1, characterized in that, Write all API calls of the image to be rendered in each frame into different target API call buffers in M×N preset API call buffers, including: According to the preset arrangement order of the API call cache, all API calls of the image to be rendered in each frame are written into different target API call caches in the preset M×N API call caches; wherein, in the M×N API call caches arranged in the preset order, N consecutive API call caches correspond to N image processing unit cores.
5. The method according to claim 4, characterized in that, Parse all API calls in the API call buffer for each target to obtain all rendering tasks corresponding to each frame of the image to be rendered, including: For each image processing unit core corresponding to M API call caches, all API calls in the M API call caches are parsed in a preset order, and the order in which the API calls in the M API call caches are parsed is the same as the order in which the API calls are written to the M API call caches.
6. The method according to claim 4, characterized in that, After obtaining all API calls for multiple frames of images to be rendered, the method further includes: The API calls for obtaining rendering resources corresponding to the current target image processing unit core, which were previously stored in the newly added resource cache, are cleared. The current target image processing unit core is the target image processing unit core corresponding to the current target API call cache that is currently writing API calls. The newly added resource cache is used to store API calls for obtaining rendering resources. Write all API calls from the newly added resource cache after clearing them into the current target API call cache. Write the API calls for obtaining rendering resources from the image to be rendered corresponding to the current target API call cache into the new resource cache.
7. The method according to claim 4, characterized in that, After obtaining all API calls for multiple frames of images to be rendered, the method further includes: Clear all API calls in the target new resource buffer area corresponding to the current target image processing unit core; wherein, the current target image processing unit core is the target image processing unit core corresponding to the current target API call buffer area that is currently writing API calls; there are N new resource buffer areas, each corresponding to one image processing unit core, and the new resource buffer area is used to store API calls for obtaining rendering resources; Write all API calls in all newly added resource buffer areas corresponding to the core of other image processing units into the current target API call buffer area; Write the API calls for obtaining rendering resources from the image to be rendered corresponding to the current target API call cache into the target new resource buffer area.
8. The method according to claim 1, characterized in that, Each API call cache stores all API calls for one frame of the image to be rendered at a time.
9. A multi-image processing unit core parallel image rendering method, characterized in that, The method, applied to the core of any image processing unit in an image processing unit, includes: The system receives and executes rendering tasks sent by the processing unit to render the image to be rendered; wherein, the rendering tasks are all rendering tasks obtained after parsing API calls in the target API call cache area corresponding to the core of the image processing unit. The target API call cache is defined as follows: an API call cache containing all API calls of at least one frame of the image to be rendered, which is written in a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
10. The method according to claim 9, characterized in that, The method further includes: Obtain the number of the image to be rendered; After rendering the image to be rendered is completed, the display buffer refresh API in the API call in the target API call cache is executed to send the rendered images to be displayed in sequence according to the number of the images to be rendered; the display buffer refresh API maintains different image numbers for different images to be rendered.
11. A multi-image processing unit core parallel image rendering method, characterized in that, include: The processing unit acquires all API calls of multiple frames of images to be rendered, and writes all API calls of each frame of the images to be rendered into different target API call caches in a preset M×N API call cache; where: N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores in the N image processing unit cores; The processing unit parses all API calls in each target API call cache to obtain all rendering tasks corresponding to each frame of the image to be rendered. The processing unit sends all rendering tasks corresponding to each frame of the image to be rendered to the core of each target image processing unit. Each of the target image processing unit cores receives and executes the rendering task sent by the processing unit to render the image to be rendered; wherein, the rendering task is all the rendering tasks obtained after parsing the API calls in the target API call cache area corresponding to the image processing unit core; The target API call cache is defined as follows: an API call cache containing all API calls of at least one frame of the image to be rendered, which is written in a preset M×N API call cache; N is a positive integer greater than 1, M is a positive integer greater than 1, each M API call cache corresponds to one image processing unit core, and at least two of the target API call caches correspond to different target image processing unit cores among the N image processing unit cores.
12. A processing unit, characterized in that, Used to perform the method as described in any one of claims 1-8.
13. An image processing unit, characterized in that, Used to perform the method as described in any one of claims 9-10.
14. An electronic device, characterized in that, include: A processing unit and an image processing unit are connected to each other. The processing unit is configured to perform the method as described in any one of claims 1-8; The image processing unit is configured to perform the method as described in any one of claims 9-10.