Frequency point control method and device, storage medium and program product

Abstract

This application provides a frequency control method, device, storage medium, and program product, relating to the field of terminal technology. The method includes: determining a first GPU load based on the GPU load of historical x frames, where x is a positive integer; determining a first GPU runtime based on the GPU runtime of historical y frames, where y is a positive integer; determining a first target frequency point based on the first GPU load and the first GPU runtime; and setting the GPU frequency point to the first target frequency point if it is determined that an increase in GPU frequency is needed. This helps to promptly set the GPU frequency point to a suitable target frequency point, thereby reducing display anomalies such as frame drops and stuttering, and improving the user experience.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a frequency control method, device, storage medium, and program product. Background Technology

[0002] The frequency of hardware components such as the graphics processing unit (GPU) and central processing unit (CPU) in a terminal device can also be understood as the operating frequency of the hardware. The hardware frequency determines the number of instructions that the hardware can execute per second. Therefore, the hardware frequency is a key factor affecting the performance and power consumption of a terminal device.

[0003] For example, since GPUs have multiple functions such as image rendering and layer compositing, their frequency has a significant impact on the smoothness of the terminal device's interface display. Therefore, current terminal devices can dynamically adjust the GPU frequency according to multiple preset levels, with each level indicating a different GPU frequency.

[0004] However, adjusting the GPU frequency in this way may still result in display anomalies such as frame drops and stuttering, leading to a poor user experience. Summary of the Invention

[0005] This application provides a frequency control method, device, storage medium, and program product, which are applied in the field of terminal technology. The terminal device can determine the target frequency based on the GPU runtime and GPU load of one or more historical frames. When the GPU frequency needs to be increased, the terminal device can determine a suitable target frequency, which helps to set the GPU frequency to a suitable target frequency in a timely manner, thereby reducing display anomalies such as frame drops and stuttering, and improving the user experience.

[0006] In a first aspect, embodiments of this application propose a frequency control method applied to a terminal device. The method includes: determining a first GPU load based on the GPU load of historical x frames, where x is a positive integer; determining a first GPU runtime based on the GPU runtime of historical y frames, where y is a positive integer; determining a first target frequency point based on the first GPU load and the first GPU runtime; and setting the GPU frequency point to the first target frequency point if it is determined that an increase in GPU frequency is needed.

[0007] In one possible implementation, the method can be executed by a terminal device, or by components such as chips, chip systems, circuits, software and / or hardware modules in the terminal device.

[0008] Wherein, the historical x-frame can be the x-frames preceding the current frame; the historical y-frame can be the y-frames preceding the current frame. The first target frequency can be determined in the current frame, for example, the nth frame, where n is a positive integer. The first GPU load can be the GPU load of the (n+1)th frame as described below. The first GPU runtime can be the GPU runtime of the (n+1)th frame as described below. The first target frequency can be the GPU frequency of the (n+1)th frame.

[0009] It's important to note that the GPU frequency in frame (n+1) can be understood as the value that the terminal device needs to adjust the GPU frequency to. This value is a suitable GPU frequency determined by the terminal device based on the GPU load and runtime of one or more historical frames. The terminal device can also set the GPU frequency to the same value as frame (n+1) in the current frame for faster frequency adjustment. In other words, the terminal device does not necessarily set the GPU frequency to the same value as frame (n+1) in the current frame.

[0010] The frequency control method of this application, when it is necessary to increase the GPU frequency, allows the terminal device to determine a suitable GPU frequency (i.e., the first target frequency) by combining the GPU load and GPU runtime of one or more historical frames, and then adjust the GPU frequency to this suitable frequency (i.e., the first target frequency). In this way, the terminal device does not need to increase the GPU frequency step by step, and can more efficiently adjust the GPU frequency to a suitable frequency, thereby helping to reduce the number of dropped frames, reduce display anomalies such as frame drops and stuttering, and thus improve the user experience.

[0011] In conjunction with the first aspect, in some possible implementations, the first GPU runtime is determined based on the first GPU load, the first offset, and the target frame length, and the first offset is determined based on the GPU runtime of the historical y-frames.

[0012] Specifically, the terminal device can adjust the first GPU runtime (the GPU runtime of the (n+1)th frame below) based on the first offset. The first offset can be the GPU margin mentioned below. The target frame length can be the frame length of the (n+1)th frame below, which is the target frame length of the (n+1)th frame, and can be the ratio of 1 to the target frame rate of the (n+1)th frame.

[0013] For example, the first GPU runtime = target frame length × first GPU load / 100 - first offset.

[0014] In this way, the first offset can be dynamically adjusted by combining the GPU runtime of historical y frames to more reasonably predict the GPU runtime (first GPU runtime), thereby determining a more suitable first target frequency point. This helps to adjust the GPU frequency point to a more suitable frequency point and reduce frame dropping and other phenomena.

[0015] In conjunction with the first aspect, in some possible implementations, the first offset is positively correlated with the GPU runtime of the historical y-frame, and the first GPU runtime is negatively correlated with the first offset.

[0016] Thus, the longer the GPU runtime of a historical y-frame, the more severe the GPU bottleneck. In this case, the first offset can be larger, and the first GPU runtime can be smaller. This helps determine a larger first target frequency, allowing the GPU frequency to be increased to a higher level, thereby resolving the GPU bottleneck and reducing frame drops. Conversely, the shorter the GPU runtime of a historical y-frame, the less severe the GPU bottleneck. In this case, the first offset can be smaller, and the first GPU runtime can be larger. This helps determine a relatively smaller first target frequency, allowing the GPU frequency to be increased to a lower level, thus avoiding resource waste.

[0017] Optionally, if the average GPU runtime of historical y-frames is greater than or equal to threshold 2, the first offset = initial value + step size × s, where s is determined based on the average GPU runtime of historical y-frames and is a positive number. If the average GPU runtime of historical y-frames is less than or equal to threshold 3, the first offset = initial value + step size × s, where s is determined based on the average GPU runtime of historical y-frames and is a negative number. Threshold 3 is less than threshold 2. When the average GPU runtime of historical y-frames is between threshold 3 and threshold 2, the first offset can be the initial value, which can be a preset value.

[0018] In conjunction with the first aspect, in some possible implementations, the method further includes: determining the GPU frequency adjustment result, which includes: a second target frequency or no GPU frequency adjustment; setting the GPU frequency to the first target frequency, including: updating the GPU frequency adjustment result to the first target frequency, and setting the GPU frequency to the first target frequency.

[0019] The GPU frequency adjustment result can be determined according to existing methods, such as... Figure 1 The method is determined. For example, it is determined in S704. Updating the GPU frequency adjustment result to the first target frequency point can be done by either using the target frequency point determined in S704 or by not adjusting the GPU frequency point and updating it to the GPU frequency point of the (n+1)th frame (the first target frequency point).

[0020] In this way, even if the GPU frequency or the second target frequency is determined using existing methods, the terminal device can update the decision to not adjust the GPU frequency or the second target frequency to a more reasonable first target frequency and set the GPU frequency to the first target frequency. This helps to adjust the GPU frequency to a more suitable level, reducing frame drops and other issues.

[0021] In conjunction with the first aspect, in some possible implementations, updating the GPU frequency adjustment result to the first target frequency and setting the GPU frequency to the first target frequency includes: when it is determined that the GPU frequency needs to be increased, setting a first flag bit to a first flag, the first flag being used to indicate increasing the GPU frequency; and updating the GPU frequency adjustment result to the first target frequency based on the first flag, and setting the GPU frequency to the first target frequency.

[0022] The first flag bit can be flag bit 1 as described below. The first flag bit is used to indicate whether the GPU frequency needs to be increased. For example, the first flag can be true as described below, indicating that the GPU frequency needs to be increased.

[0023] In this way, the terminal device can determine whether it needs to update the GPU frequency adjustment result determined by the existing method to the first target frequency using the first flag bit.

[0024] In conjunction with the first aspect, in some possible implementations, the method further includes: setting a second flag to a first flag when it is determined that there is no need to increase the GPU frequency, the second flag indicating that the GPU frequency should not be increased; and setting the GPU frequency to a second target frequency based on the second flag, or not adjusting the GPU frequency.

[0025] The second flag can be, for example, "No" as shown below, indicating that the GPU frequency does not need to be increased.

[0026] In this way, when there is no need to increase the GPU frequency, the terminal device can adjust the GPU frequency according to the existing method based on the second marker. This allows the terminal device to adjust the GPU frequency to the primary target frequency in situations requiring increased GPU frequency, such as multiple application scenarios, to more efficiently boost the GPU frequency and reduce frame dropping in multiple application scenarios. When there is no need to increase the GPU frequency, the GPU frequency can be adjusted according to the existing method, reducing resource waste.

[0027] In conjunction with the first aspect, in some possible implementations, the terminal device includes a first scheduling module, which is used to dynamically adjust the GPU frequency; the GPU frequency adjustment result is determined by the first scheduling module.

[0028] The first scheduling module can be the governor component mentioned below, or simply the regulator.

[0029] In conjunction with the first aspect, in some possible implementations, it is determined that the GPU frequency needs to be increased, including: at a first timing, based on a first duration greater than or equal to a first threshold, it is determined that the GPU frequency needs to be increased. The first timing belongs to the stage of determining whether the GPU task has been completed. The first duration is related to the first stage, which is the stage of adding the rendered buffer to the display buffer queue.

[0030] The stage for determining whether a GPU task has completed execution can be the `plane_wait_input_fence` stage, or the stage where the `plane_wait_input_fence` function is called. That is, the terminal device can determine whether to increase the GPU frequency during the `plane_wait_input_fence` stage. The first duration can be the queue buffer time. The displayed queue buffer can be the queue managed by the surface flinger (SF), such as queue 2 below. The first threshold can be threshold 1 below.

[0031] Thus, when the first duration is greater than or equal to the first threshold, it indicates that the GPU rendering time may be long, requiring an increase in GPU frequency to trigger the terminal device to increase its GPU frequency. When the first duration is less than the first threshold, it indicates that the GPU rendering time may be short, requiring no increase in GPU frequency to trigger the terminal device to adjust its GPU frequency according to the existing GPU frequency adjustment method. Furthermore, since the first timing is used to determine whether the GPU task has been completed, it allows for a more accurate and efficient determination of whether a GPU bottleneck exists (i.e., whether the first duration is greater than or equal to the first threshold).

[0032] In conjunction with the first aspect, in some possible implementations, the method further includes: determining a third target frequency point based on a first frame length and a target frame length; setting the CPU frequency point to the third target frequency point; wherein the first frame length is the frame length calibrated based on a second duration and / or a third duration, and / or the target frame length is determined based on the GPU frequency point of historical consecutive z frames and / or the GPU runtime of historical consecutive z frames; the second duration is related to the second stage, which is the stage of obtaining a free buffer from the free buffer queue; the third duration is related to the third stage, which is the waiting stage before submitting the rendered buffer to the display buffer queue.

[0033] The first frame length can be the calibration frame length described below. The second duration can be duration 2 described below, i.e., dequeueBufferTime. The second stage can be the dequeueBufferTime stage. The third duration can be duration 1 described below, i.e., queueBufferWaitTime. The third stage can be the queueBufferWaitTime stage. The first frame length is the frame length calibrated based on the second duration and / or the third duration, including: the first frame length is the frame length minus the difference between the second duration and the third duration.

[0034] The target frame length can be the ratio of 1 to the target frame rate of the next frame determined based on method 900. The third target frequency can be the target value of the CPU frequency mentioned below.

[0035] Thus, when GPU bottlenecks exist, the time spent on GPU rendering and compositing can be long, potentially increasing the frame length (duration of one frame). Therefore, to avoid excessively increasing the CPU frequency, the frame length can be calibrated. Since the second and third frame lengths are often caused by GPU bottlenecks, the first frame length can be the frame length minus the difference between the second and / or third frame lengths. This prevents the terminal device from excessively increasing the CPU frequency based on the first frame length, helping to reduce resource waste.

[0036] In addition, the GPU frequency and / or GPU runtime of consecutive historical z-frames can reflect whether the performance bottleneck of the terminal device is on the GPU side. Therefore, the target frame length can be determined based on the GPU frequency and / or GPU runtime of consecutive historical z-frames.

[0037] In conjunction with the first aspect, in some possible implementations, the target frame length is determined based on the GPU frequency of historical consecutive z frames and / or the GPU runtime of historical consecutive z frames, including: when the GPU frequency of each frame in historical consecutive z frames is the maximum value, and / or when the GPU runtime of each frame in historical consecutive z frames is greater than or equal to a second threshold, the target frame length is the average or weighted average of the frame lengths of historical consecutive z frames.

[0038] The maximum value can be the maximum value within the adjustable range of the GPU frequency. The second threshold can be threshold 4 as described below. The GPU frequency of each frame in the historical consecutive z frames is the maximum value, and / or the GPU runtime of each frame in the historical consecutive z frames is greater than or equal to the second threshold. This can indicate that the performance bottleneck of the terminal device is on the GPU side, which can reduce the target frame rate, that is, increase the target frame length, so that the terminal device does not increase the CPU frequency too much.

[0039] Since the target frame length is the ratio of 1 to the target frame rate, the target frame length being the average or weighted average of the frame lengths of the historical consecutive z frames can also be understood as the target frame rate (i.e., the target frame rate of the next frame below) being the average frame rate of the historical consecutive z frames or the weighted average of the frame rates of the historical consecutive z frames. This is similar to the implementation of method 900.

[0040] Secondly, embodiments of this application provide a frequency control device, which can be a terminal device, or a chip or chip system within the terminal device. The frequency control device may include a processing unit. When the frequency control device is a terminal device, the processing unit may be a processor. The frequency control device may also include a storage unit, which may be a memory. The storage unit stores instructions, and the processing unit executes the instructions stored in the storage unit to cause the terminal device to implement a frequency control method described in the first aspect or any possible implementation of the first aspect. When the frequency control device is a chip or chip system within the terminal device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to cause the electronic device to implement a frequency control method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit within the chip (e.g., a register, cache, etc.), or a storage unit located outside the chip within the terminal device (e.g., a read-only memory, random access memory, etc.).

[0041] For example, a processing unit is used to determine a first target frequency point and set the GPU frequency point as the first target frequency point.

[0042] Thirdly, embodiments of this application provide a terminal device, including a processor and a memory, wherein the memory is used to store code instructions and the processor is used to run the code instructions to perform the method described in the first aspect or any possible implementation of the first aspect.

[0043] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0044] Fifthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0045] Sixthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0046] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0047] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0048] Figure 1 This is a schematic diagram illustrating the process of adjusting GPU frequency.

[0049] Figure 2 This is a schematic diagram of an interface for multiple application scenarios;

[0050] Figure 3 This is a schematic diagram illustrating the process of generating an interface to be displayed.

[0051] Figure 4 A schematic diagram illustrating the interaction between the software architecture and hardware of the terminal device provided in the embodiments of this application;

[0052] Figure 5 This is a flowchart illustrating a frequency control method.

[0053] Figure 6 This application provides a schematic diagram of a process for generating image data for a display interface.

[0054] Figure 7 A flowchart illustrating the frequency control method provided in this application embodiment;

[0055] Figure 8 This is a schematic diagram illustrating the process of determining the target value of the CPU frequency point provided in an embodiment of this application.

[0056] Figure 9 A flowchart illustrating the method for determining a target frame rate provided in an embodiment of this application;

[0057] Figure 10A schematic block diagram illustrating the hardware architecture of the terminal device provided in the embodiments of this application;

[0058] Figure 11 A schematic block diagram of a frequency control device provided in an embodiment of this application. Detailed Implementation

[0059] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0060] 1. Frame rate (frames per second, FPS)

[0061] Frame rate refers to the number of frames displayed per second, measured in Hz. It's a metric for measuring the smoothness of applications (especially graphics-intensive applications such as games or video playback applications). A higher frame rate results in smoother visuals, but also places higher demands on the computing power and resources of the terminal device.

[0062] Frame length: The time interval between frame updates, for example, 1 / FPS.

[0063] 2. Expected Frames Per Second (EFPS)

[0064] Also known as the target frame rate, EFPS is a specific target frame rate that developers expect their application to achieve on particular hardware. For some applications, especially graphics-intensive ones like games or video playback, each application may have its own target EFPS. EFPS represents the frame rate target that developers want their application to achieve on specific hardware. On high-performance devices, EFPS may be set higher, while on low-end devices, it may be set lower.

[0065] Normally, during application runtime, FPS can equal EFPS. However, when the application has a high thread load, FPS may be less than EFPS.

[0066] The target frame length can be 1 / EFPS.

[0067] 3. Layer buffer

[0068] It can also be simply called a buffer. Each application window or graphics component typically corresponds to one layer. The application draws these layers into the buffer through the rendering process. These buffers store the rendering results of the application window, and SF uses these buffers to composite the layers.

[0069] 4. Frame buffer

[0070] The frame buffer is a memory area that stores image data (or pixel data). It typically consists of pixel data generated by the GPU or CPU. The frame buffer is usually located in the memory inside the system on chip (SOC), or it may be located in a separate video memory (such as GDDR5 or GDDR6) and managed by a separate GPU.

[0071] After obtaining the layer buffers of each application, SF will composite these layers (which can be understood as layer compositing or overlay processing) to obtain the image data of a frame of the interface to be displayed. This image data is stored in the frame buffer.

[0072] 5. dequeueBufferTime

[0073] This refers to the time required to retrieve a free buffer from buffer queue 1. During graphics rendering, the application needs to obtain a free buffer from buffer queue 1 in order to begin rendering a new frame. `dequeueBufferTime` reflects the efficiency of this process.

[0074] For example, if no free buffer is available in buffer queue 1, the application's rendering thread may be blocked until a free buffer becomes available. In this case, dequeueBufferTime may be too long, thus affecting the frame rate.

[0075] 6. queueBufferWaitTime

[0076] This refers to the time spent waiting before the rendered buffer is placed into buffer queue 2. If the display system (such as SF) processes the buffers in buffer queue 2 slowly, or if buffer queue 2 is full, the application may need to wait, resulting in a longer queueBufferWaitTime.

[0077] 7. Terminal equipment

[0078] The terminal devices in this application embodiment may include handheld devices, vehicle-mounted devices, etc., with frequency adjustment functions. For example, some electronic devices include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future evolution of public land mobile communication networks. Terminal devices in a network (PLMN), etc., are not limited to this in the embodiments of this application.

[0079] By way of example and not limitation, in this embodiment, the electronic device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0080] Furthermore, in this embodiment of the application, the electronic device can also be a terminal device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0081] The terminal device in this application embodiment may also be referred to as: electronic device, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user equipment, etc.

[0082] In this embodiment, the electronic device or various network devices include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0083] 8. Other terms

[0084] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0085] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0086] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0087] The GPU in a terminal device performs multiple functions, including image rendering, layer compositing, and video decoding and encoding. Therefore, the GPU's operating status has a significant impact on the performance of the terminal device and the user experience.

[0088] To improve user experience while preventing excessive power consumption on end devices, the device can adjust the GPU frequency based on GPU utilization (GPU_busy). GPU utilization can also be understood as GPU load, which indicates the workload or usage of the tasks processed by the GPU. Higher GPU utilization or GPU load may mean that the GPU is handling more complex tasks, potentially leading to higher power consumption and temperature.

[0089] It should be understood that GPU frequency, also known as GPU clock speed or GPU operating frequency, is usually measured in megahertz (MHz) or gigahertz (GHz). GPU frequency determines the GPU's clock speed, that is, the number of instruction cycles that can be executed per second. GPU frequency is one of the key factors affecting its performance and power consumption. A higher GPU frequency generally results in higher GPU performance but higher power consumption; conversely, a higher GPU frequency generally results in lower GPU performance but lower power consumption. The following description uses GPU frequency as an example.

[0090] Currently, terminal devices can adjust the GPU frequency and voltage according to the dynamic voltage and frequency scaling (DVFS) mechanism.

[0091] For example, under high GPU load (such as running complex 3D games or graphics applications), a terminal device can increase the GPU frequency to improve GPU performance, allowing the GPU to complete tasks promptly. Furthermore, since higher GPU frequencies typically require higher voltage to maintain stable operation, the terminal device can also increase the voltage when increasing the GPU frequency. Conversely, under low GPU load, the terminal device can decrease both the GPU frequency and voltage.

[0092] The following is combined with Figure 1 This section explains how to adjust the GPU frequency in scenarios with high GPU load.

[0093] Figure 1 This is a schematic diagram illustrating a process for adjusting GPU frequency. (Example) Figure 1 As shown, from time t1 to time t2, the GPU frequency can be at level 1, and the GPU utilization rate is consistently higher than a certain threshold, such as 90%. This indicates that the GPU is continuously under high load. Therefore, the terminal device can increase the GPU frequency, for example, from level 1 to level 2. The GPU frequency corresponding to level 2 is higher than that corresponding to level 1.

[0094] It should be understood that terminal devices can preset multiple GPU frequency levels (also known as tiers), with different levels corresponding to different GPU frequencies. In scenarios with high GPU load, terminal devices can gradually increase the GPU frequency.

[0095] After increasing the GPU frequency to level 2, if the GPU utilization remains above a certain threshold (e.g., 90%) between time t2 and time t3, it indicates that the GPU is still under high load. In this case, the terminal device can continue to increase the GPU frequency, for example, from level 2 to level 3. The GPU frequency corresponding to level 3 is higher than that corresponding to level 2.

[0096] If the GPU utilization drops below 90% after the GPU frequency is increased to level 3, then the GPU frequency corresponding to level 3 is the appropriate GPU frequency.

[0097] However, the time interval from t1 to t2 (or from t2 to t3) may include multiple frames. This means that the GPU frequency was only increased when the GPU utilization remained above 90% for several consecutive frames. Therefore, in scenarios with multiple applications running, the above method of adjusting the GPU frequency may result in untimely adjustments, leading to a higher number of dropped frames, lower screen smoothness, and even stuttering or other display anomalies, resulting in a poor user experience.

[0098] Multi-application running scenarios can include running different applications via floating windows or split-screen modes. For example, running an application via a floating window... Figure 2 As shown, while the terminal device displays the interface of application 1 (such as a game application) in full screen, it also displays the interface of application 2 (such as a social application) in a floating window 201. Furthermore, in response to the user's upward swipe input, the interface of application 2 scrolls within the floating window 201. At this time, application 1 and application 2 are running in the foreground on the terminal device. In this multi-application running scenario, the terminal device needs to render the interfaces of multiple applications, which may increase the scheduling pressure on the GPU, as detailed below.

[0099] Figure 3 This is a schematic diagram illustrating the process of generating a display interface. That is, through... Figure 3 The process shown allows the terminal device to synthesize and... Figure 2 Image data similar to those in a user interface. For example... Figure 3 As shown, the process may include the following steps:

[0100] S01. The rendering thread of application 1 obtains a free buffer from the buffer queue 1, which may be referred to as buffer 1. The rendering thread of application 2 obtains another free buffer from the buffer queue 1, which may be referred to as buffer 2.

[0101] Buffer queue 1 can also be called the free buffer queue. Buffer queue 1 can contain one or more free buffers. Free buffers are those that have not yet cached image data. The rendering thread can, for example, call the `dequeueBuffer` method to obtain free buffers.

[0102] S02. The rendering thread of application 1 can submit (or instruct) rendering task 1 to the GPU. Rendering task 1 is used to instruct the rendering of UI components and graphic elements of application 1, and the rendered image data is cached in buffer 1. The rendering thread of application 2 can submit (or instruct) rendering task 2 to the GPU. Rendering task 2 is used to instruct the rendering of UI components and graphic elements of application 2, and the rendered image data is cached in buffer 2.

[0103] Buffer 1 may include one or more buffers; Buffer 2 may also include one or more buffers.

[0104] S03. The rendering thread of application 1 sets (or adds) the rendered buffer 1 to buffer queue 2. The rendering thread of application 2 sets (or adds) the rendered buffer 2 to buffer queue 2.

[0105] Buffer queue 2 may include one or more buffers, which can be image data drawn and rendered by the rendering threads of various applications. Buffer queue 2 can be managed by SF. Buffer queue 2 may also be called a display buffer, etc.

[0106] S04 and SF can retrieve buffers from buffer queue 2 and can instruct the hardware composer (HWC) to retrieve a portion of the buffers (or layers) from buffer queue 2 for HWC compositing; they can also retrieve a portion of the buffers (or layers) from buffer queue 2 via the GPU for GPU compositing.

[0107] HWC compositing can be understood as overlaying layers using HWC, or compositing layers using HWC. GPU compositing can be understood as overlaying layers using the GPU, or compositing layers using the GPU. The image data in each buffer of buffer queue 2 can also be understood as a layer.

[0108] The image data of the interface to be displayed, obtained after S05, HWC compositing, and GPU compositing, is cached in the frame buffer. Subsequently, the terminal device can flush the image data in the frame buffer to the display screen for display. In this way, the terminal device's display screen can display images such as... Figure 2 The interface shown.

[0109] pass Figure 3 The process illustrated shows that in scenarios with multiple applications running, the GPU not only needs to handle rendering tasks for multiple applications but may also need to perform some layer compositing. This places a significant scheduling burden on the GPU, resulting in high performance requirements. Furthermore, when applications running on the terminal device need to continuously update (scroll) the interface content based on user input (such as swiping up in the floating window 201), the performance demands on the GPU are even higher. In such cases, if the GPU frequency cannot be increased in time, it may lead to a large number of dropped frames, or even stuttering and other display anomalies, resulting in a poor user experience.

[0110] In view of this, this application provides a frequency control method. On the one hand, the terminal device can adjust the GPU frequency based on existing methods; on the other hand, when it is determined that the GPU frequency needs to be increased, the terminal device can also determine a first target frequency (the predicted GPU frequency for the next frame) based on the GPU load and GPU runtime of one or more historical frames. Furthermore, the terminal device can update the GPU frequency adjustment result determined based on existing methods to the first target frequency and adjust the GPU frequency to the first target frequency.

[0111] In this way, when it is determined that the terminal device needs to increase the GPU frequency, the terminal device does not need to increase the GPU frequency step by step. It can adjust the GPU frequency to a suitable frequency more efficiently, which helps to reduce the number of dropped frames and display abnormalities such as frame drops and stuttering, thereby improving the user experience.

[0112] The following is combined with Figures 4 to 9 The technical solutions of this application and how they solve the aforementioned technical problems are described in detail with specific embodiments. The following specific embodiments can be implemented independently or in combination with each other. Identical or similar concepts or processes may not be described again in some embodiments.

[0113] The embodiments shown in this application can be executed by a terminal device, a chip, chip system, or processor that supports the frequency control method in the terminal device, or a logic module or software that can implement all or part of the functions of the terminal device. This application does not impose specific limitations in this regard.

[0114] The embodiments of this application are described below using a terminal device as the execution subject. The specific form and number of devices shown are merely examples and should not constitute any limitation on the implementation of the methods provided in this application.

[0115] To facilitate understanding, the following will be combined with... Figure 4 Taking the layered architecture of the Android system as an example, this paper illustrates the software architecture of a terminal device.

[0116] The software system of the terminal device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture.

[0117] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into six layers, from top to bottom: the application layer, the application framework (FWK) layer, the Android runtime and system libraries, the hardware abstraction layer (HAL), and the kernel layer.

[0118] 1. Application Layer

[0119] An application can include a series of application packages. For example, the application layer can include application packages such as browsers, games, video, gallery, telephone, music, and social applications.

[0120] As is understandable, each application in the application layer typically runs in its own process. A process is the basic unit by which the operating system allocates resources (such as memory, CPU time, etc.). A process can contain multiple threads (including logic threads, UI threads, and rendering threads). The rendering thread is a background thread used to handle interface drawing. Therefore, applications can use their respective rendering threads to draw UI components, graphical elements, and other displayed content.

[0121] 2. Application Framework Layer

[0122] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0123] The application framework layer may include the window manager service (WMS) and the activity manager service (AMS), etc.

[0124] The window manager can be used to manage window applications. For example, it can obtain the screen size, determine whether there is a status bar, lock the screen, and capture the screen.

[0125] The Activity Manager can be used to launch activities and manage their lifecycle. It can also be used to manage application launches; for example, a desktop launcher can use the Activity Manager to launch an application's activity, or other applications can use the Activity Manager to launch their activities.

[0126] 3. System libraries (native) and Android runtime

[0127] It can include multiple functional modules. For example, SF, 3D graphics processing libraries (e.g., OpenGL ES), etc.

[0128] Among them, SF is Android's Display Compositing Service, which is responsible for managing the layers of all applications. These layers can also be understood as the image data drawn by each application in the buffer through the rendering thread.

[0129] SF can combine layers from multiple applications into a single final frame using HWC and GPU.

[0130] The 3D graphics processing library can convert rendering instructions from the application into OpenGL commands, and then call the GPU through the GPU driver to execute the OpenGL commands so that UI components and graphic primary colors can be rendered by the GPU.

[0131] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0132] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0133] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0134] 4. The Hardware Abstraction Layer (HAL) primarily serves to connect the application framework layer and the kernel layer. It abstracts the underlying hardware details, allowing upper-layer software to be unaware of the specific hardware implementation. The HAL may include the Hardware-in-the-Box (HWC) and control modules, etc. The display HAL provides the interface with the display hardware.

[0135] HWC can composite layers from parts of an application, or it can be understood as overlaying layers from parts of an application.

[0136] The control module can be used to adjust the target frequency determined by the kernel-level frequency modulation (devfreq) architecture. It can also be used to assist in adjusting the CPU frequency. For details, please refer to the description in method 600; further details will not be provided here.

[0137] 5. The kernel layer is the layer between hardware and software. In an exemplary embodiment, the kernel layer includes the display driver, GPU driver, CPU driver, and devfreq architecture.

[0138] The devfreq architecture can be understood as an architecture used to dynamically adjust the GPU frequency. The devfreq architecture can include multiple components, such as the devfreq framework component, the governor component, and the operating performance points (OPP) device component. These three components enable dynamic adjustment of the GPU frequency.

[0139] The devfreq framework component is used to manage GPU frequency adjustments. It can obtain the target frequency from the governor component and adjust the GPU frequency to the target frequency through the OPP device component.

[0140] The governor component can be understood as a policy module that can obtain information such as GPU load from the OPP device component in order to determine the target frequency based on the GPU load information.

[0141] The OPP device component can switch the GPU's frequency and voltage based on the target frequency indicated by the devfreq framework component.

[0142] For example, Figure 5 This is a flowchart illustrating the GPU frequency adjustment method 500 provided in an embodiment of this application. Figure 5 As shown, method 500 includes the following steps:

[0143] The S501 devfreq framework component instructs the governor component to acquire the target frequency.

[0144] For example, the devfreq framework component can obtain the target frequency from the governor component by calling get_target_freq(). get_target_freq() can be understood as a function or method used to obtain the target frequency from the governor component.

[0145] The S502 governor component instructs the OPP device component to obtain current load information. Load information may include, for example, GPU utilization (or GPU load), task queue length, frame rendering time, etc.

[0146] For example, the governor component can obtain load information from the OPP device component by calling devfreq_updates_stats().

[0147] S503, the OPP device component indicates this load information to the governor component.

[0148] Based on this load information, the S504 and governor components determine the target frequency.

[0149] For example, with Figure 1Similarly, the governor component can increase the GPU frequency by one level when the GPU utilization is greater than or equal to a certain threshold (such as 90%) for a certain period of time. The target frequency is the GPU frequency after the increase of one level.

[0150] Alternatively, if the GPU utilization rate is less than or equal to a certain threshold (such as 60%) for a certain period of time, the GPU frequency can be reduced by one level. The target frequency determined by the governor component is the GPU frequency after the reduction by one level.

[0151] Alternatively, if the GPU utilization is within a certain range (e.g., 60% to 90%), the governor component can determine that no GPU frequency adjustment is needed. The governor component can then instruct the devfreq framework component not to adjust the GPU frequency.

[0152] If the governor component determines that the GPU frequency needs to be adjusted, S505 to S507 can be executed.

[0153] The S505 governor component indicates the target frequency to the devfreq framework component.

[0154] The S506 devfreq framework component instructs the OPP device component to set the GPU frequency to the target frequency.

[0155] For example, the devfreq framework component can instruct the OPP device component to set the GPU frequency to the target frequency by calling devfreq->profile->target().

[0156] The S507 OPP device component indicates the GPU frequency setting result to the devfreq framework component. For example, it indicates whether the GPU frequency was successfully set to the target frequency, or whether the GPU frequency was not successfully set to the target frequency.

[0157] In addition to the layered software architecture described above, terminal devices can also include a hardware layer. Modules in the software architecture can interact with the hardware in the hardware layer.

[0158] 6. The hardware layer includes the display controller, display screen, GPU, and GPU, etc.

[0159] The display screen can be used to show image data. The GPU can be used for rendering and layer compositing.

[0160] The display controller can transfer pixel data from the frame buffer to the display screen for display.

[0161] It should be noted that, Figure 4 The software architecture shown is for illustrative purposes only. Terminal devices may include more or fewer software modules; for example, the application layer may include applications such as cameras and maps. Figure 4 The software architecture shown does not constitute a limitation on the embodiments of this application.

[0162] Combination Figure 4 The illustrated architecture allows terminal devices to adjust the GPU frequency in the following ways. To facilitate understanding of the specific methods for adjusting the GPU frequency in the embodiments of this application, the following will first explain... Figure 6 The method 600 shown illustrates the process of displaying an interface on a terminal device.

[0163] Figure 6 This is a flowchart illustrating an interface display method 600 provided in an embodiment of this application. Figure 6 As shown, method 600 includes the following steps:

[0164] S601, Application 1 adds buffer 1 to buffer queue 2.

[0165] There can be one or more buffers in buffer 1. Each buffer in buffer 1 can be understood as the rendering (or drawing) result of a layer.

[0166] Buffer queue 2 can be understood as a queue for SF, so that subsequent SF can perform layer composition based on the buffers in buffer queue 2.

[0167] S602, Application 2 adds buffer 2 to buffer queue 2.

[0168] There can be one or more buffers 2. Each buffer in buffer 2 can be understood as the rendering (or drawing) result of a layer.

[0169] It should be understood that the implementation methods of S601 and S602 are different from those of S602. Figure 3 The implementation methods of S01 to S03 are similar and can be referred to the description above, so they will not be repeated here.

[0170] S603 and SF retrieve buffer 1 and buffer 2 from buffer queue 2.

[0171] S604 and SF wake up the GPU and instruct the GPU to perform GPU compositing to obtain a frame buffer.

[0172] In this context, GPU compositing can be understood as the GPU performing overlay processing (or layer compositing processing) on ​​some or all of the layers in buffer 1 and buffer 2.

[0173] It should be noted that, in addition to GPU compositing, SF can also instruct HWC to perform HWC compositing, that is, HWC can also overlay some or all of the layers in buffer 1 and buffer 2.

[0174] After GPU compositing and HWC compositing are completed, a frame buffer is obtained. The frame buffer can cache the pixel data of a frame of image to be displayed.

[0175] It should be understood that the implementation methods of S603 to S604 are the same as those of S604. Figure 3 The implementation methods for S04 to S05 are similar and can be referred to the description above, so they will not be described in detail here.

[0176] This can be understood as follows: after the frame buffer is drawn, SF can indicate to Application 1 and Application 2 that the interface drawing is complete. Application 1 and Application 2 can then send a page flipping request to the display driver, allowing the display driver to update the interface displayed on the terminal device through subsequent steps. For example, based on the page flipping request, the display driver can execute S605.

[0177] S605, the display driver sets the display parameters in stage 1; and obtains the frame buffer in stage 1, and sends the frame buffer to the display controller.

[0178] Phase 1 can be understood as the phase where the display driver submits (or instructs) the drawn frame buffer to the display controller. During this phase, the display driver can also configure the display controller; these configurations can be called display parameters, such as resolution and refresh rate.

[0179] For example, stage 1 can also be called the crtc_commit stage, or it can be understood as the stage in which the display driver calls the crtc_commit function.

[0180] It's understandable that sub-stage 1 exists within stage 1. Sub-stage 1 can be understood as the stage where the display driver determines whether the GPU's tasks have been completed. For example, in scenarios with multiple applications running, HWC compositing and GPU compositing are typically required for the application's layers; in addition, the GPU also needs to perform rendering and some computation. Therefore, the GPU's scheduling pressure is relatively high. To ensure that the image data in the framebuffer can be displayed correctly, the display driver can also confirm in sub-stage 1 whether all GPU tasks have been completed.

[0181] For example, sub-phase 1 can be understood as the plane_wait_input_fence phase, or as the phase in which the explicit driver calls the plane_wait_input_fence function.

[0182] Therefore, in sub-stage 1, it can generally be assumed that the GPU's tasks have been completed. Thus, in this embodiment, the terminal device can add a "stub" in sub-stage 1 to trigger a determination of whether the current GPU frequency meets performance requirements, thereby determining whether it is necessary to boost the GPU frequency.

[0183] It should be understood that in the embodiments of this application, a "stub" can also be understood as a timing or a predefined location, and this location can trigger the terminal device to execute a predefined process. For example, if a "stub" is added in sub-stage 1, then at that "stub", the terminal device can be triggered to determine whether it is necessary to increase the GPU frequency.

[0184] In one possible implementation, the terminal device can determine whether the GPU frequency needs to be increased by: determining whether the queue buffer time is greater than or equal to a threshold of 1; if yes, it indicates that the GPU frequency needs to be increased; if no, it indicates that the GPU frequency does not need to be increased.

[0185] Threshold 1 can be a preset duration. The queue buffer can be understood as the stage where rendered buffers (such as buffer1 and buffer2) are added to (or submitted to) buffer queue 2 for subsequent compositing and display. The queue buffer time can include dequeueBufferTime and queueBufferWaitTime, as well as other times.

[0186] Queue buffer latency may include the time spent waiting for GPU rendering to complete. If the GPU rendering task is not completed, queue buffer operations may be blocked, increasing queue buffer latency. Therefore, queue buffer latency can reflect the duration of GPU rendering, thus indicating whether there are performance issues with the GPU. Consequently, queue buffer latency can be used to determine whether the GPU frequency needs to be increased.

[0187] When the queue buffer time is greater than or equal to threshold 1, it indicates that the GPU rendering time may be long, and the GPU frequency needs to be increased. The terminal device can set flag 1 to true to trigger the terminal device to increase the GPU frequency. When the queue buffer time is less than threshold 1, it indicates that the GPU rendering time may be short, and the GPU frequency does not need to be increased. The terminal device can set flag 1 to false to trigger the terminal device to adjust the GPU frequency according to the existing GPU frequency adjustment method.

[0188] Here, flag 1, also known as gpuBoundFlag, can be understood as a flag used to indicate whether GPU clock speed needs to be increased (or to indicate whether a GPU bottleneck exists). Flag 1 can be set to true or false. Alternatively, it can be replaced with other flags, such as 0 or 1, etc., which are not specifically limited in this application.

[0189] The flag set by flag bit 1 can influence the process of adjusting the GPU frequency in the terminal device. For example, in existing GPU frequency control methods, as described in method 500, the terminal device determines the target frequency to be adjusted through a regulator component. Furthermore, in some possible scenarios, the regulator may also determine that no GPU frequency adjustment is needed, thus instructing the frequency tuning framework component not to adjust the GPU frequency. However, by combining the flag set by flag bit 1, the GPU frequency control method provided in this application embodiment can update the GPU frequency adjustment result determined by the regulator component (such as the target frequency determined by the regulator component, or the determination that no GPU frequency adjustment is needed) when flag bit 1 is set to true. Specifically, as follows... Figure 7 The process is shown in the diagram.

[0190] It should be understood that the steps shown above for determining whether to increase the GPU frequency and setting the flag bit to 1 can be performed by the display driver, by the rendering thread of application 1 or application 2, or by other modules or threads. This application does not specifically limit these steps.

[0191] Figure 7 This is a flowchart illustrating a frequency adjustment method 700 provided in an embodiment of this application. Figure 7 As shown, method 700 includes the following steps:

[0192] The S701 devfreq framework component instructs the governor component to acquire the target frequency.

[0193] S702, the governor component instructs the OPP device component to obtain the load information of the nth frame. The load information of the nth frame may include, for example, the GPU load of the nth frame. Here, the nth frame can be understood as the current frame, and n is a positive integer.

[0194] S703, the OPP device component indicates the payload information of the nth frame to the governor component.

[0195] The S704 and governor components determine the target frequency based on the load information of the nth frame.

[0196] It should be understood that the implementation methods of S701 to S704 are similar to those of S501 to S504, and can be understood as existing GPU frequency adjustment methods.

[0197] In S704, the governor component may determine whether the GPU frequency needs to be increased or decreased, and can determine the target frequency. Alternatively, the governor component may also determine that the GPU frequency does not need to be increased.

[0198] The difference from method 500 is that, in this embodiment, the target frequency determined by the governor component can also be updated via S706 to S711. Alternatively, if the governor component also determines that it is not necessary to increase the GPU frequency, it can instruct the governor component to adjust the GPU frequency to a higher frequency. Details are as follows.

[0199] S705, the control module obtains the GPU load of historical x frames from the governor component.

[0200] The GPU load of historical x frames includes the GPU load of each frame in the historical x frames. x can be a preset positive integer, such as 3.

[0201] It is understandable that the GPU load of historical x frames can be obtained by the governor component from the OPP device component. Furthermore, the GPU load for each frame can be calculated based on the GPU runtime and GPU frequency of that frame.

[0202] For example, GPU load, GPU runtime, and GPU frequency satisfy the following formula: GPU load = GPU runtime × GPU frequency. This formula can then be used to determine the GPU load for each frame in the historical x frames.

[0203] Optionally, "stubs" can be added to the `tz_get_target_freq` function in the governor component. This allows the control module to retrieve the GPU load of historical x frames from the governor component when the governor component calls the `tz_get_target_freq` function to determine the target frequency. It can also trigger the control module to update the target frequency determined by the governor component.

[0204] S706. Determine the GPU load for frame n+1 based on the historical GPU load of frame x.

[0205] It should be understood that since the current frame is frame n, the GPU load in frame n+1 can be understood as the load predicted based on the GPU load of historical frames x.

[0206] For example, the GPU load of frame n+1 can be the average or weighted average of the GPU load of historical frames x. For instance, the closer a frame is to frame n, the greater its corresponding weight can be.

[0207] S707, calculates the average GPU runtime for historical y-frames.

[0208] The GPU runtime of the historical y-frame can be obtained by the control module from the governor component, and the governor component can be obtained from the OPP device component. y can be a preset positive integer, such as 0 or 3.

[0209] S708. Determine the GPU runtime for the (n+1)th frame based on the historical average GPU runtime of the y-th frame.

[0210] It should be understood that since the current frame is frame n, the GPU runtime of frame n+1 can be understood as the GPU runtime predicted based on the GPU runtime of historical frames y. The GPU runtime of frame n+1 can also be referred to as allowTime, for example.

[0211] In one possible implementation, the GPU runtime of the (n+1)th frame can be determined in the following way.

[0212] For example, the GPU runtime of frame (n+1) = frame length of frame (n+1) × GPU load of frame (n+1) / 100 - GPU margin. Here, GPU margin can be understood as the offset of GPU runtime. Furthermore, GPU margin can be determined based on the average GPU runtime of historical frames (y).

[0213] If the average GPU runtime of historical y frames is greater than or equal to a threshold of 2, it indicates a longer GPU runtime. Therefore, a larger GPU margin can be allocated to minimize the GPU runtime in the (n+1)th frame, thereby increasing the GPU frequency. For example, GPU margin = initial value + step size × s, where s can be determined based on the average GPU runtime of historical y frames; the larger the average GPU runtime of historical y frames, the larger s.

[0214] For example, the terminal device can have a preset function 1, which is used to convert the average GPU runtime of historical y frames into s. The step size can be a preset duration, such as 50 milliseconds (ms), and the initial value can also be a preset duration. The threshold 2 can be a preset value.

[0215] Furthermore, if the average GPU runtime of historical y frames is less than or equal to the threshold 3, the GPU margin can be smaller so that the GPU runtime of the (n+1)th frame is larger, thereby allowing for a smaller increase in GPU frequency, or no increase in GPU frequency at all.

[0216] For example, GPU margin = initial value + step size × s. Here, s can be determined based on the average GPU runtime of historical y-frames. The smaller the average GPU runtime of historical y-frames, the smaller s, and s can be negative. Alternatively, GPU margin = initial value - step size × s. Here, s can be determined based on the average GPU runtime of historical y-frames, and s is a positive number. The initial value can be a preset value.

[0217] The terminal device can have a preset function 2, which is used to convert the average GPU runtime of historical y frames into s. The step size can be a preset duration, such as 50ms, and the initial value can also be a preset duration. Preset function 2 can be the same as or different from preset function 1. Threshold 3 can be a preset value. Threshold 2 and threshold 3 can be the same. Alternatively, threshold 3 can be less than threshold 2.

[0218] It should be understood that terminal devices may also have other pre-configured algorithms or models to convert the average GPU runtime of historical y-frames into GPU margin, where the larger the average GPU runtime of historical y-frames, the larger the GPU margin; and the smaller the average GPU runtime of historical y-frames, the smaller the GPU margin. This application does not impose specific limitations in this regard.

[0219] Furthermore, when threshold 3 is less than threshold 2, and the average GPU runtime of historical y frames is less than threshold 2 but greater than threshold 3, then the GPU margin can be equal to the initial value. Alternatively, the GPU runtime of the (n+1)th frame can be equal to the average GPU runtime of historical y frames.

[0220] In other words, if the average GPU runtime over historical y frames is less than threshold 2 and greater than threshold 3, it indicates that the GPU runtime is moderate, and there is no need to further improve GPU performance or further reduce power consumption. Therefore, no adjustment to the GPU margin is required.

[0221] The frame length of the (n+1)th frame can be equal to 1 / the frame rate of the (n+1)th frame, also known as the target frame length. The frame rate of the (n+1)th frame can also be understood as the target frame rate or ideal frame rate. The target frame rate of the (n+1)th frame can be the application's target frame rate, or it can be determined by... Figure 9 The target frame rate is determined in the manner shown.

[0222] It should be understood that the average GPU runtime of historical y frames can also be replaced by a weighted average of the GPU runtime of historical y frames. This application does not specifically limit this.

[0223] S709. Based on the GPU runtime and GPU load of the (n+1)th frame, determine the GPU frequency point of the (n+1)th frame.

[0224] For example, the GPU load in frame (n+1) = GPU runtime in frame (n+1) × GPU frequency in frame (n+1). Based on this, the GPU frequency in frame (n+1) can be calculated.

[0225] S710, the control module determines whether the flag bit 1 is true.

[0226] If flag 1 is not true, for example, if it is false, it means that the GPU frequency does not need to be increased, and the control module does not need to indicate the GPU frequency of frame n+1 to the governor component. That is, the control module does not need to execute subsequent processes.

[0227] When flag 1 is true, it indicates that the GPU frequency needs to be increased, and the governor component can execute S711.

[0228] S711, the control module indicates the GPU frequency point of frame n+1 to the governor component. This causes the governor component to modify the calculated target frequency point to the GPU frequency point of frame n+1. Alternatively, if the governor component determines that no adjustment of the GPU frequency point is needed, the governor component uses the GPU frequency point of frame n+1 as the target frequency point.

[0229] For example, the aisched_set_gpufreq node can be added to the tz_get_target_freq function to trigger the update of the target frequency determined by the governor component to the GPU frequency of the (n+1)th frame (or to trigger the governor component to indicate the GPU frequency of the (n+1)th frame to the devfreq framework component).

[0230] The S712 governor component indicates the target frequency (i.e., the GPU frequency of the (n+1)th frame) to the devfreq framework component.

[0231] The S713 devfreq framework component instructs the OPP device component to set the GPU frequency to the target frequency (i.e., the GPU frequency of the (n+1)th frame).

[0232] S714, the OPP device component indicates the GPU frequency setting result to the devfreq framework component. For example, it indicates whether the GPU frequency was successfully set to the target frequency (i.e., the GPU frequency of frame n+1), or whether the GPU frequency was not successfully set to the target frequency (i.e., the GPU frequency of frame n+1).

[0233] Although the frequency point determined by the control module is called the GPU frequency point of the (n+1)th frame, this name is only to indicate that this frequency point is the frequency point predicted by the control frequency point, and does not require the terminal device to adjust the GPU frequency point to the target frequency point (i.e., the GPU frequency point of the (n+1)th frame) in the (n+1)th frame. For example, after the control determines the GPU frequency point of the (n+1)th frame, the terminal device can adjust the GPU frequency point to the target frequency point (i.e., the GPU frequency point of the (n+1)th frame) through S711 to S714.

[0234] It should be understood that the implementation methods of S712 to S714 are similar to those of S505 to S507, and can be referred to the description above, which will not be repeated here.

[0235] It is understandable that S710 can also be executed before S705, or before any of the steps S705 to S709, so that if the control module determines that the flag bit 1 is not true, the control module does not need to determine the GPU frequency point of the (n+1)th frame, thereby reducing the power consumption of the terminal device.

[0236] In the frequency control method of this application, the terminal device can determine whether there is a GPU bottleneck problem (i.e., the GPU frequency cannot meet the performance requirements and the GPU frequency needs to be increased) in the plane_wait_input_fence stage; and when there is a GPU bottleneck problem, it can determine a higher GPU frequency (i.e., the GPU frequency of the n+1th frame mentioned above) based on the GPU load and GPU runtime of one or more historical frames, so as to set the GPU frequency to the GPU frequency of the n+1th frame through the governor component.

[0237] In this way, since the plane_wait_input_fence stage is the stage to determine whether all GPU tasks in the current frame have been completed, it can more accurately and efficiently determine whether a GPU bottleneck problem exists when judging whether a GPU bottleneck problem exists in this stage.

[0238] Furthermore, when a GPU bottleneck exists, the process of adjusting the GPU frequency by the governor component can be intervened. This allows the governor component to increase the GPU frequency, reducing the likelihood that it will either not increase or decrease the GPU frequency when a bottleneck is present. This enables efficient increases in GPU frequency when a bottleneck exists. Especially in multi-application scenarios, when the terminal device determines that a GPU bottleneck exists, increasing the GPU frequency in the current frame can reduce frame drops, decrease the number of dropped frames, reduce stuttering and other anomalies, improve the smoothness of the terminal device's display, and enhance the user experience.

[0239] It's understandable that when GPU bottlenecks exist, the time spent on GPU rendering and compositing can be longer, potentially increasing the frame length (duration of one frame). This can lead to the terminal device increasing the CPU frequency based on the frame length being less than or equal to the target frame length. However, since the increased frame length is caused by the GPU bottleneck, increasing the CPU frequency may not reduce the frame length or the number of dropped frames. Therefore, when GPU bottlenecks exist, terminal devices can adjust the CPU frequency in the following ways.

[0240] In one possible implementation, the control module calibrates the frame length to obtain a calibrated frame length, and adjusts the CPU frequency based on the calibrated frame length. This process can be as follows: Figure 8 As shown, the process can include 5 stages.

[0241] Phase 1: The control module determines the calibration frame length.

[0242] It's understandable that when GPU issues exist, Flash Render (SF) needs to wait for the GPU to complete rendering tasks, which may cause SF to sleep for a period of time until the GPU finishes rendering. This sleep time is included in the frame length of the next frame, causing the terminal device to determine the next frame length to be greater than the actual frame length. When the terminal device needs to adjust the CPU frequency based on the next frame length, because the terminal device determines the next frame length to be greater than the actual frame length, it may determine that the next frame length is less than or significantly less than the target frame length. This leads the terminal device to increase the CPU frequency, and the increase may be substantial.

[0243] To make CPU frequency adjustments more accurate, when determining the frame length of the next frame, the frame length obtained by the terminal device can be subtracted from the sleep time.

[0244] For example, the calibration frame length (i.e. the actual frame length of the next frame) = the frame length of the next frame - minus the sleep time.

[0245] In this way, the control module can adjust the CPU frequency based on the calibration frame length, so that the control module will not increase the CPU frequency too much based on a larger frame length, which helps to reduce resource waste and reduce the power consumption of the terminal device.

[0246] This sleep period can include a duration of 1. Duration 1 can be understood as the time the terminal device waits before placing the rendered buffer into buffer queue 2. Duration 1 can also be called queueBufferWaitTime, which can be a duration within the queueBuffer process.

[0247] In addition to `queueBufferWaitTime`, the frame length of the next frame obtained by the terminal device also includes `duration2`. `duration2` refers to the time required for the terminal device to retrieve a free buffer from buffer queue 1; `duration2` can also be called `dequeueBufferTime`. This time can also be understood as the time SF needs to wait. Therefore, the calibration frame length = next frame length - `duration1` - `duration2`. This allows for a more accurate determination of the calibration frame length, thereby helping to further reduce resource waste.

[0248] It is understandable that the control module can obtain duration 1 and duration 2 from the rendering thread, and determine the calibration frame length based on duration 1, duration 2 and the frame length of the next frame.

[0249] Phase 2: The control module can determine the frame length difference based on the calibration frame length and the target frame length. For example, frame length difference = calibration frame length - target frame length.

[0250] Phase 3: The control module can also determine the frame rate loss (FPSLoss) of the frame length difference based on the frame length difference of multiple consecutive frames.

[0251] The consecutive frames can include the next frame mentioned above. The frame length difference between each frame in the consecutive frames can be determined in the manner described above. The frame rate loss can be the average or weighted average of the frame length differences of the consecutive frames.

[0252] Phase 4: Determine the target value of CPU frequency based on frame rate loss.

[0253] For example, the terminal device can dynamically adjust the CPU frequency through a reinforcement learning (RL) model. The control module can input a determined frame rate loss into the RL model, allowing the RL model to output a target value for the CPU frequency based on the frame rate loss. This allows the CPU frequency to be subsequently adjusted to that target value.

[0254] It should be understood that frame rate loss can also be called RL frame rate loss (RL FPS Loss). This application does not specifically limit it in this regard.

[0255] In this way, since the frame length of each frame in a series of consecutive frames is the calibrated frame length, the frame rate loss calculated by the control module is highly accurate. This ensures that the target value of the CPU frequency point determined by the RL model based on the frame rate loss will not be too high, which helps to reduce resource waste and lower the power consumption of the terminal device.

[0256] As can be seen from the above methods of adjusting CPU frequency, in addition to the frame length affecting the target CPU frequency value determined by the terminal device, the target frame length also affects the target CPU frequency value. Therefore, the terminal device can also adjust the target CPU frequency value by adjusting the target frame length.

[0257] It's understandable that increasing the CPU frequency might not resolve frame drops when a GPU bottleneck exists. Therefore, if frame drops are determined to be caused by a GPU bottleneck, the terminal device can reduce the target frame rate.

[0258] Figure 9 This is a flowchart illustrating a method 900 for determining a target frame rate. Method 900 can be executed by a control module. Figure 9 As shown, method 900 includes the following steps:

[0259] S901, the control module determines whether all consecutive historical z-frames are GPU overload frames.

[0260] In this context, assuming the current frame is frame n, then the consecutive historical frames z can be frames nz to n-1. A GPU overload frame can be understood as a frame where the GPU frequency is at its maximum value and the GPU times out. A GPU timeout can also be understood as the GPU runtime being greater than or equal to a threshold of 4. The threshold of 4 can be a preset value. z is a preset positive integer, such as 30, 60, etc.

[0261] If all consecutive historical z-frames are GPU overload frames, the control module executes S902, which adjusts the target frame rate of the next frame to the average frame rate of the consecutive historical z-frames (or a weighted average of the frame rates of the consecutive historical z-frames). The average frame rate of the consecutive historical z-frames can also be understood as the average of the frame rates of the consecutive historical z-frames. Adjusting the target frame rate of the next frame to the average frame rate of the consecutive historical z-frames can also be replaced by setting the target frame length of the next frame to the average frame length of the consecutive historical z-frames.

[0262] Since the historical consecutive z-frames were all GPU overload frames, it means that the frame rate of each frame in the historical consecutive z-frames may be low, and the frame length may be long. Therefore, the average frame rate of the historical consecutive z-frames is also low. By adjusting the target frame rate of the next frame to the average frame rate of the historical consecutive z-frames, it is equivalent to lowering the target frame rate of the next frame. This allows the terminal device to determine a lower target value for the CPU frequency, without excessively increasing the CPU frequency.

[0263] If consecutive historical z-frames are not all GPU overload frames, the control module executes S903 and does not adjust the target frame rate for the next frame.

[0264] Thus, if all consecutive z-frames in the historical records are GPU overload frames, it indicates that the current frame drop issues are mainly due to GPU bottlenecks, allowing the target frame rate to be reduced. When the terminal device adjusts the CPU frequency based on the target frame rate, the reduced target frame rate results in a smaller frame rate loss, allowing the terminal device to set a smaller target CPU frequency. This reduces resource waste and lowers the terminal device's power consumption.

[0265] It should be understood that the sequence numbers in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic.

[0266] The frequency control method of the present application has been described above. The apparatus for executing the above-described frequency control method provided in the embodiments of the present application will now be described. Those skilled in the art will understand that the methods and apparatus can be combined with and referenced in each other, and the related apparatus provided in the embodiments of the present application can execute the steps in the above-described frequency control method.

[0267] First, combine Figure 10 Describe the hardware structure of the electronic device.

[0268] Figure 10 This is a schematic diagram of the structure of the terminal device 1000 provided in an embodiment of this application. Figure 10 As shown, the terminal device 1000 may include a processor 1010, an external memory interface 1020, an internal memory 1021, a universal serial bus (USB) interface 1030, a charging management module 1040, a power management module 1041, a battery 1042, an antenna 1, an antenna 2, a mobile communication module 1050, a wireless communication module 1060, an audio module 1070, a sensor module 1080, a button 1090, a motor 1091, an indicator 1092, a camera 1093, a display screen 1094, and a subscriber identification module (SIM) card interface 1095, etc.

[0269] The audio module 1070 may include a speaker, receiver, microphone, and headphone jack. The sensor module 1080 may include a pressure sensor, gyroscope sensor, barometric pressure sensor, magnetic sensor, accelerometer, distance sensor, proximity sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor, bone conduction sensor, etc.

[0270] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the terminal device 1000. In other embodiments of this application, the terminal device 1000 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0271] The processor 1010 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (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). These different processing units may be independent devices or integrated into one or more processors.

[0272] For example, methods 500, 600, 700 and 900 may be executed by processor 1010.

[0273] In some examples, processor 1010 can be a system-on-chip (SOC) of terminal device 1000.

[0274] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0275] The processor 1010 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 1010 is a cache memory. This memory can store instructions or data that the processor 1010 has just used or that are used repeatedly. If the processor 1010 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 1010, and thus improves the efficiency of the system.

[0276] In some embodiments, the processor 1010 may include one or more interfaces.

[0277] The terminal device 1000 implements display functions through a GPU, a display screen 1094, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 1094 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 1010 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0278] The display screen 1094 is used to display images, videos, etc. The display screen 1094 includes a DDIC and a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal device 1000 may include one or N display screens 194, where N is a positive integer greater than 1.

[0279] Internal memory 1021 can be used to store computer executable program code, which includes instructions. Internal memory 1021 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of terminal device 1000 (such as audio data, phonebook, etc.). Furthermore, internal memory 1021 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 1010 executes various functional applications and data processing of terminal device 1000 by running instructions stored in internal memory 1021 and / or instructions stored in memory located in the processor.

[0280] Figure 11 This is a schematic block diagram of a frequency control device 1100 provided in an embodiment of this application. The device 1100 includes a processor 1101, a communication interface 1102, and a memory 1103. The processor 1101, communication interface 1102, and memory 1103 communicate with each other via internal connections. The memory 1103 stores instructions, and the processor 1101 executes the instructions stored in the memory 1103. The communication interface 1102 can be used to send signals to other devices (e.g., the processor 1101 or the display screen of a terminal device) and to receive signals from other devices (e.g., the memory 1103). Exemplarily, the communication interface 1102 reads instructions stored in the memory 1103 and sends the instructions to the processor 1101.

[0281] It should be understood that the device 1100 may specifically be the terminal device in the above embodiments, and may be used to execute the various steps and / or processes corresponding to the terminal device in the above method embodiments. Optionally, the memory 1103 may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store device type information. The processor 1101 may be used to execute instructions stored in the memory, and when the processor 1101 executes instructions stored in the memory, the processor 1101 is used to execute the various steps and / or processes in the above method embodiments.

[0282] It should be understood that in the embodiments of this application, the processor can be a CPU, or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0283] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or as a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor executes the instructions in the memory, combining them with its hardware to complete the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0284] The frequency control method provided in this application can be applied to terminal devices. The specific device form of the terminal device can be referred to the above-mentioned description, and will not be repeated here.

[0285] This application provides a terminal device, which includes a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the terminal device to perform the above-described method.

[0286] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0287] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0288] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0289] This application provides a computer program product, which includes a computer program that, when run, causes a computer to perform the above-described method.

[0290] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0291] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A frequency control method, characterized in that, Applied to a terminal device, the method includes: The first GPU load is determined based on the GPU load of historical x frames, where x is a positive integer. The first GPU runtime is determined based on the GPU runtime of historical y frames, where y is a positive integer; The first target frequency point is determined based on the first GPU load and the first GPU runtime; If it is determined that the GPU frequency needs to be increased, the GPU frequency is set to the first target frequency.

2. The method according to claim 1, characterized in that, The first GPU runtime is determined based on the first GPU load, the first offset, and the target frame length. The first offset is determined based on the GPU runtime of the historical y-frame.

3. The method according to claim 2, characterized in that, The first offset is positively correlated with the GPU runtime of the historical y-frame, and the first GPU runtime is negatively correlated with the first offset.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Determine the GPU frequency adjustment result, which includes: a second target frequency or no GPU frequency adjustment; Setting the GPU frequency to the first target frequency includes: The GPU frequency adjustment result is updated to the first target frequency, and the GPU frequency is set to the first target frequency.

5. The method according to claim 4, characterized in that, The step of updating the GPU frequency adjustment result to the first target frequency and setting the GPU frequency to the first target frequency includes: If it is determined that the GPU frequency needs to be increased, the first flag is set to indicate that the GPU frequency needs to be increased; Based on the first marker, the GPU frequency adjustment result is updated to the first target frequency, and the GPU frequency is set to the first target frequency.

6. The method according to claim 5, characterized in that, The method further includes: If it is determined that there is no need to increase the GPU frequency, the first flag is set to the second flag, which is used to indicate that the GPU frequency should not be increased; Based on the second marker, the GPU frequency can be set to the second target frequency, or the GPU frequency can be left unchanged.

7. The method according to any one of claims 4 to 6, characterized in that, The terminal device includes a first scheduling module, which is used to dynamically adjust the GPU frequency; the GPU frequency adjustment result is determined by the first scheduling module.

8. The method according to any one of claims 1 to 7, characterized in that, The determination that the GPU frequency needs to be increased includes: At a first opportune moment, based on a first duration greater than or equal to a first threshold, it is determined that the GPU frequency needs to be increased; wherein, the first opportune moment belongs to the stage of determining whether the GPU task has been completed, the first duration is related to the first stage, and the first stage is the stage of adding the rendered buffer to the display buffer queue.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The third target frequency point is determined based on the first frame length and the target frame length; Set the CPU frequency of the central processing unit to the third target frequency. Wherein, the first frame length is the frame length calibrated based on the second duration and / or the third duration, and / or the target frame length is determined based on the GPU frequency of historical consecutive z frames and / or the GPU runtime of the historical consecutive z frames; the second duration is related to the second stage, which is the stage of obtaining free buffers from the free buffer queue; the third duration is related to the third stage, which is the waiting stage before submitting the rendered buffer to the display buffer queue; and z is a positive integer.

10. The method according to claim 9, characterized in that, The target frame length is determined based on the GPU frequency points of historical consecutive z-frames and / or the GPU runtime of the historical consecutive z-frames, including: If the GPU frequency point of each frame in the historical consecutive z frames is the maximum value, and / or the GPU runtime of each frame in the historical consecutive z frames is greater than or equal to the second threshold, the target frame length is the average or weighted average of the frame lengths of the historical consecutive z frames.

11. A terminal device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the terminal device to perform the method as described in any one of claims 1-10.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

13. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 1-10.

Images