WO2024093491A9

WO2024093491A9 - Performance regulation method and electronic device

Info

Publication number: WO2024093491A9
Application number: PCT/CN2023/116072
Authority: WO
Inventors: 相超; 刘鹏程
Original assignee: 荣耀终端有限公司
Priority date: 2022-10-31
Filing date: 2023-08-31
Publication date: 2024-07-18
Also published as: WO2024093491A1; CN117950935A

Abstract

A performance regulation method and an electronic device (100). The performance requirement of the electronic device (100) can be determined according to a current user scenario of the electronic device (100), and the performance parameters of the electronic device (100) are adjusted according to the performance requirement of the electronic device (100), the performance parameters comprising at least one of the TDP power consumption of a CPU, the TGP power consumption of a GPU, the TPP power consumption of the GPU, and the DB power consumption of the GPU, so that a display card performs performance regulation according to the current TDP, TPP, TGP and/or DB power consumption, so as to provide more reasonable CPU and GPU performances according to the scenario, the performance requirements of a user in various scenario are better met, and the service life of the device is relatively prolonged, thereby improving the user experience.

Description

Performance control method and electronic equipment

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on October 31, 2022, with application number 202211345647.9 and application name “A performance control method and electronic device”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the technical field of intelligent terminals, and in particular to a performance control method and an electronic device.

Background technique

With the continuous development of electronic technology, electronic devices such as laptops or portable computers have been widely developed as common devices in people's daily life and work. There are various configurations of laptops on the market. For example, many laptops are equipped with independent graphics cards to provide higher performance. The increase of independent graphics cards generally means an increase in device power consumption, and given the mobile nature of laptops, battery life has always been the focus of users. How to optimize the performance, battery life, heat generation, etc. of electronic devices such as laptops or portable computers has always been the focus of users.

Summary of the invention

In order to solve the above technical problems, the present application provides a performance control method and an electronic device. In the performance control method, the performance parameters of the electronic device can be adjusted according to the current user scenario of the electronic device, so that the graphics card can perform performance control according to the current TDP, TPP, TGP and/or DB power consumption, so that more reasonable CPU and GPU performance can be provided according to the scenario, which not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

In a first aspect, the present application provides a performance control method, which is applied to an electronic device, wherein the electronic device includes a central processing unit (CPU) and a graphics processing unit (GPU), and the method includes:

In response to a user operation, a first application is started. Before the first application is started, a first performance parameter of the electronic device is a first parameter value, and the first performance parameter includes at least one of a TDP power consumption of the CPU, a TGP power consumption of the GPU, a TPP power consumption of the GPU, and a DB power consumption of the GPU;

After starting the first application, at a first time point, a first performance parameter of the electronic device is adjusted to a second parameter value, the second parameter value being different from the first parameter value;

In response to a user operation, closing the first application and starting a second application;

After starting the second application, at a second time point, the first performance parameter of the electronic device is adjusted to a third parameter value, and the third parameter value is different from the second parameter value.

According to the first aspect, the performance requirement of the electronic device can be determined according to the application currently running on the electronic device, and the first performance parameter of the electronic device can be adjusted according to the performance requirement of the electronic device, and the first performance parameter includes at least one of the TDP power consumption of the CPU, the TGP power consumption of the GPU, the TPP power consumption of the GPU, and the DB power consumption of the GPU. One method is to enable the graphics card to adjust its performance according to the current TDP, TPP, TGP and/or DB power consumption, so as to provide more reasonable CPU and GPU performance according to the scenario, which not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

According to the first aspect, or any implementation of the first aspect above, the method further includes:

In response to a user operation, a third application is started, and before the third application is started, a second performance parameter of the electronic device is a fourth parameter value, and the second performance parameter includes a Dx value of the GPU;

After starting the third application, at a third time point, adjusting the second performance parameter of the electronic device to a fifth parameter value, the fifth parameter value being different from the fourth parameter value;

In response to a user operation, closing the third application and starting a fourth application;

After starting the fourth application, at a fourth time point, the second performance parameter of the electronic device is adjusted to a sixth parameter value, and the sixth parameter value is different from the fifth parameter value.

With such a setting, the performance requirements of the electronic device can be determined according to the current user scenario of the electronic device, and the second performance parameter of the electronic device can be adjusted according to the performance requirements of the electronic device. The second performance parameter includes the Dx value of the GPU, so that the graphics card performs performance regulation according to the power consumption corresponding to the current Dx value, thereby providing a more reasonable GPU performance according to the scenario, which not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

Before a fifth time point, a second performance parameter of the electronic device is a seventh parameter value, the second performance parameter includes a Dx value of the GPU, and the fifth time point is after the first time point and/or the second time point;

At a fifth time point, adjusting the second performance parameter of the electronic device to an eighth parameter value, wherein the eighth parameter value is different from the seventh parameter value;

The remaining battery power of the electronic device at the fifth time point is less than the remaining battery power at the first time point and/or the second time point, and the electronic device is not plugged in at the fifth time point; or

The temperature of the electronic device at the fifth time point is greater than the temperature at the first time point and/or the second time point.

This setting can reduce device heat or power consumption and improve device battery life by limiting GPU power consumption when the temperature of the electronic device is too high or the battery is low.

Determine a user scenario of the electronic device according to the first application, and determine a value of the second parameter according to the user scenario of the electronic device;

The user scenario of the electronic device is determined according to the second application, and the size of the third parameter value is determined according to the user scenario of the electronic device.

With such a setting, the performance parameters of the electronic device can be adjusted according to the current user scenario of the electronic device, so that the graphics card can perform performance regulation according to the current TDP, TPP, TGP and/or DB power consumption, thereby providing more reasonable CPU and GPU performance according to the scenario, which not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

Sending the second parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the second parameter value;

The third parameter value is sent to the GPU driver, and the GPU driver controls the performance of the GPU according to the third parameter value.

This setting allows the graphics card to adjust its performance based on the current TDP, TPP, TGP and/or DB power consumption, thereby providing more reasonable CPU and GPU performance based on the scenario. It not only better meets the user's performance requirements in various scenarios, but also can relatively improve the device's battery life, thereby improving the user experience.

According to the first aspect, or any implementation of the first aspect above, the electronic device further includes BIOS and ACPI,

Sending the second parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the second parameter value, includes:

Transmitting the second parameter value to the BIOS via a WMI interface;

The BIOS writes the second parameter value into the first performance parameter storage location specified by the ACPI, and reads the second parameter value through the GPU driver;

The GPU driver reads the second parameter value, and controls the performance of the GPU according to the second parameter value;

Sending the third parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the third parameter value, includes:

Transmitting the third parameter value to the BIOS via a WMI interface;

The BIOS writes the third parameter value into the first performance parameter storage location specified by the ACPI, and reads the second parameter value through the GPU driver;

The GPU driver reads the third parameter value and controls the performance of the GPU according to the third parameter value.

This setting can send the current parameter value of the first performance parameter to the GPU driver through the WMI interface and BIOS, ensuring that the GPU driver obtains the current parameter value stably and timely, and performs performance control according to the current parameter value.

Sending the fifth parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the fifth parameter value;

The sixth parameter value is sent to the GPU driver, and the GPU driver controls the performance of the GPU according to the sixth parameter value.

This setting allows the graphics card to adjust performance according to the current Dx value, thereby providing more reasonable CPU and GPU performance according to the scenario. It not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

The fifth parameter value is sent to the GPU driver, and the GPU driver controls the GPU performance, including:

Transmitting the fifth parameter value to the BIOS via a WMI interface;

The BIOS writes the fifth parameter value into the second performance parameter storage location specified by the ACPI, and reads the third parameter value through the GPU driver;

The GPU driver reads the fifth parameter value and controls the performance of the GPU according to the fifth parameter value;

Sending the sixth parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the sixth parameter value, includes:

Transmitting the sixth parameter value to the BIOS via a WMI interface;

The BIOS writes the sixth parameter value into the second performance parameter storage location specified by the ACPI, and reads the sixth parameter value through the GPU driver;

The GPU driver reads the sixth parameter value and controls the performance of the GPU according to the sixth parameter value.

This setting can send the current parameter value of the second performance parameter to the GPU driver through the WMI interface and BIOS, ensuring that the GPU driver obtains the current parameter value stably and timely, and performs performance control according to the current parameter value.

In a second aspect, the present application provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the performance control method in the first aspect or any possible implementation of the first aspect.

In a third aspect, the present application provides a computer-readable medium for storing a computer program, wherein the computer program includes instructions for executing the method in the first aspect or any possible implementation of the first aspect.

In a fourth aspect, the present application provides a computer program, comprising instructions for executing the method in the first aspect or any possible implementation of the first aspect.

In a fifth aspect, the present application provides a chip, the chip comprising a processing circuit and a transceiver pin, wherein the transceiver pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the method in the first aspect or any possible implementation of the first aspect to control the receiving pin to receive a signal and control the sending pin to send a signal.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram showing an exemplary module interaction of a current temperature monitoring method;

FIG2 is a schematic diagram showing a hardware structure of an electronic device;

FIG3 is a schematic diagram showing an exemplary software structure of an electronic device;

FIG4 is a schematic diagram of interaction between software modules provided in an embodiment of the present application;

FIG5 is a schematic diagram of a signal interaction provided in an embodiment of the present application;

FIG6 is an interface diagram provided in an embodiment of the present application;

FIG7 is another schematic diagram of signal interaction provided in an embodiment of the present application;

FIG8 is a flow chart of a performance control method provided in an embodiment of the present application;

FIG9 is an example control process of the performance control method provided in an embodiment of the present application;

FIG10 is another exemplary control process of the performance control method provided in an embodiment of the present application;

FIG. 11 shows a schematic block diagram of a device according to an embodiment of the present application.

Detailed ways

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

The term "and/or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects. For example, a first target object and a second target object are used to distinguish different target objects rather than to describe a specific order of target objects.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" refers to two or more than two. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

In order to make the description of the following embodiments clear and concise, a brief introduction to related concepts or technologies is first given:

Motherboard BIOS: Basic Input Output System. BIOS is a set of programs that are fixed to a ROM chip on the motherboard of the computer. It stores the most important basic input and output programs of the computer, system setting information, power-on self-test program and system boot program. The main function of BIOS is to provide the lowest-level and most direct hardware settings and control for the computer. The interfaces provided by BIOS to the operating system include BS (Boot Services) and RT (Runtime Services).

Graphics BIOS: BIOS is also called VGA BIOS or Video BIOS. It is mainly used to store the control program between the display chip and the driver. It controls various working states of the graphics card, including core operating frequency, video memory operating frequency, power consumption limit, operating voltage, video memory timing and other core parameters. The graphics card BIOS chip is used to save the graphics card BIOS program. Like the motherboard BIOS, the graphics card BIOS is stored in the BIOS chip instead of the disk.

NVAPI: NVAPI is an interface provided by NVIDIA (NVIDIA/Nvidia) for third-party calls to monitor the temperature, performance parameters, etc. of graphics cards.

ACPI: Advanced Configuration and Power Interface, ACPI is the interface between system hardware/firmware (BIOS) and OS (operating system) and OS application. In other words, BIOS provides communication between operating system and hardware through a unified interface, and ACPI is an implementation of this unified interface in BIOS. ACPI provides two types of data structures for the operating system (OS): data tables and definition blocks. They are OS (operating system) The ACPI interface is an interface for the BIOS/EFI firmware to interact with the system. The data table stores raw data and is used by the device driver. The definition block consists of bytecodes that can be executed by the interpreter. The data table part is generated by the firmware (BIOS/EFI) and is used to describe various aspects of the system hardware. The ACPI interface contains many predefined tables, the definitions of which are stored in the BIOS chip and generated by the BIOS into the memory and submitted to the operating system.

ACPI Control Method: ACPI control method is similar to the function in C language. The function of AML is called Method. According to the ACPI specification, BIOS provides some standard methods for OS to call, such as _PTS, _WAK, etc. The control method defines how OS performs a simple hardware task. For example, OS calls the control method (ControlMethod) to read the temperature of a high temperature area.

WMI: Windows Management Instrumentation, Windows Management Specification, provides a unified interface for any local or remote application or script to obtain management data from a computer system, network, or enterprise. The design of this unified interface makes it unnecessary for WMI client applications and scripts to call various operating system application programming interfaces (APIs).

NVIDIA Dynamic Boost: is a new technology that more intelligently allocates power to the CPU and GPU of a laptop, thereby improving the power efficiency of the laptop under the premise of limited power consumption, thereby improving the overall performance of the laptop.

Dx-Notify: A performance control interface reserved for NVIDIA graphics cards. Dx-Notify supports 5 levels of performance control from D1 to D5. Each level corresponds to different GPU performance. You can set the corresponding performance of D1-D5 in Video BIOS. D1 has the strongest performance and D5 has the weakest performance.

SCI: System Control Interrupt, system control interrupt. An IRQ (interrupt request) specifically used for ACPI power management, which requires OS (operating system) support.

SMI: System Management Interrupt, a special interrupt used by the system to enter SMM (System Management Mode).

SMM: System Management Mode, system management mode, is a standard architecture feature that is unified for all Intel processors. System Management Mode (SMM) provides the same execution environment as the System Management Interrupt (SMI) handler in the traditional IA-32 architecture.

TGP: Total Graphics Power, generally refers to the performance/power consumption of the entire graphics card.

TDP: CPU Thermal Design Power, thermal design power consumption, its meaning is "when the processor reaches the maximum load, the amount of heat released" (unit: watt (W)), is an indicator of the heat release of a processor. In application, TDP is an indicator that reflects the heat release of the processor, and it is the maximum heat limit that the computer's cooling system must be able to dissipate.

TPP power consumption: Total Processor Power, total processor power consumption. For laptops, it generally refers to CPU power consumption + GPU power consumption.

DB power consumption: dynamic power consumption of the graphics card, that is, the upper and lower limits of the dynamic adjustment of the TGP power consumption of the graphics card. For example, if the TGP power consumption is 40W and the DB power consumption is 15W, the graphics card driver can limit the graphics card power consumption to between 25W and 55W based on the current power consumption/actual power consumption of the CPU.

Single baking/dual baking: The baking machine is a stability test of the computer. Single baking means that the software (such as AIDA64Extreme) runs a stress test of a certain component alone, such as GPU and FPU single baking. Double baking means that the software allows two tests to be performed at the same time, generally referring to the CPU and GPU working at full load.

Address information: used to indicate the location information of the pre-applied memory. The CPU/program can obtain the specific location of the pre-applied memory through the address information, and store parameters such as GPU temperature, CPU temperature, motherboard temperature, fan speed, etc. in the memory. There are many ways to indicate the address information. The address information can be the starting position and length of the memory, or the starting position and end position of the memory. All address information that can be used to indicate the location of the memory is applicable to the present application embodiment.

The focus window is the window that has the focus. The focus window is the only window that can receive keyboard input. The way the focus window is determined is related to the system's focus mode. The top window of the focus window is called the active window. Only one window can be the active window at the same time. The focus window is most likely the window that the user needs to use at the moment.

The focus mode can be used to determine how the mouse gives focus to a window. Generally, there are three focus modes:

(1) Click-to focus. In this mode, the window clicked by the mouse will get the focus. That is, when the mouse clicks anywhere on a window that can get the focus, the window will be activated, and the window will be placed in front of all windows and receive keyboard input. When the mouse clicks on other windows, the window will lose the focus.

(2) Focus-follow-mouse: In this mode, the window under the mouse can obtain the focus. That is, when the mouse moves into the range of a window that can obtain the focus, the user can activate the window and receive keyboard input without clicking anywhere in the window, but the window is not necessarily placed in the front of all windows. When the mouse moves out of the range of the window, the window will also lose the focus.

(3) Sloppy focus. This focus mode is similar to focus-follow-mouse: when the mouse moves into the range of a window that can receive focus, the user does not need to click anywhere in the window to activate the window and receive keyboard input, but the window is not necessarily placed in the front of all windows. Unlike focus-follow-mouse, when the mouse moves out of the window range, the focus does not change. The system focus changes only when the mouse moves to another window that can receive focus.

A process includes multiple threads, and a thread can create a window. The focus process is the process to which the thread that creates the focus window belongs.

Among all the chips or processors of a laptop or portable computer (Laptop), the CPU (central processing unit) and GPU (graphics processing unit) are the chips with the highest power consumption and the most difficult to control performance. How to control the performance, power consumption, and heat generation of the CPU and GPU has always been a difficult point in performance regulation of laptops or portable computers (Laptop). The purpose of the embodiments of the present application is to control the graphics card performance and power consumption based on user scenarios of electronic devices such as laptops, thereby achieving control of the performance and power consumption of the entire machine.

Figure 1 is a schematic diagram of module interaction of a current performance control method. In the example shown in Figure 1, adjusting the Dx value of an NV (ie, NVIDIA) graphics card (ie, the Dx value in Dx-Notify) is used as an example to illustrate the current graphics card performance control process.

In this application, graphics card, GPU, graphics processing unit or graphics processor have the same meaning and represent the same component in the device. Graphics cards can be divided into integrated graphics cards and independent graphics cards. In the embodiments of this application, the performance of independent graphics cards is adjusted as an example for explanation. However, it should be understood that the performance control method disclosed in the embodiments of this application is also applicable to integrated graphics cards. In addition, in the embodiments of this application, NV graphics cards are used as an example for explanation, but the performance control method disclosed in the embodiments of this application is also applicable to other graphics cards.

As shown in FIG1 , current methods for controlling the performance of a graphics card of an electronic device include:

S101, a controller (EC) reads the temperature of a graphics card from a temperature sensor outside the graphics card.

Exemplarily, the controller (EC) is connected to communicate with a temperature sensor outside the graphics card via, for example, a system management bus ("SMBus"), and polls the temperature sensor or other devices via the system management bus ("SMBus") to read the temperature of the graphics card from the temperature sensor outside the graphics card.

S102, the controller (EC) determines the Dx value of the graphics card according to the temperature of the graphics card.

The controller determines the current Dx value of the graphics card based on the current temperature of the graphics card according to the relationship between the preset temperature and the Dx value. For example, when the current temperature of the graphics card exceeds the upper limit temperature corresponding to D4, the controller (EC) determines to adjust the Dx value of the graphics card to D5 to reduce the performance of the graphics card, thereby reducing the temperature of the graphics card.

S103, the controller (EC) notifies the BIOS to switch the graphics card Dx value.

Exemplarily, the controller (EC) transmits data through the 62/66IO port. The BIOS and the controller (EC) predefine the SMI (System Management Interrupt) interrupt number, and the BIOS or more specifically the BIOS runtime service obtains the interrupt number from the controller (EC) through the 62/66IO port. After the controller (EC) determines the Dx value of the graphics card, an SCI interrupt is generated, and the BIOS runtime service calls the interrupt service function corresponding to the interrupt number to read the Dx value of the graphics card again through the 62/66IO port.

S104, BIOS modifies the Dx value and notifies the graphics card driver to read the Dx value.

Exemplarily, ACPI specifies a storage location in the internal memory (ie, memory) for storing Dx values. After reading the Dx value, the BIOS modifies the Dx value at the storage location to the latest value, and then notifies the graphics card driver to read the latest Dx value.

S105, the graphics card driver reads the Dx value, and controls the graphics card according to the power consumption corresponding to the Dx value.

Specifically, the BIOS will generate an SCI interrupt after modifying the Dx value. After receiving the SCI interrupt (that is, event notification), the graphics card driver calls the graphics card control method (graphics card control method defined in ACPI) to read the current value of Dx.

When the current value of Dx is read, the graphics card performance is controlled according to the power consumption corresponding to the current value of Dx. For example, if the current Dx value is D3 and the corresponding graphics card power consumption is 15W, the graphics card driver controls the graphics card to limit its maximum power consumption to 15W.

As for the specific power consumption corresponding to the current value of Dx, it can be obtained from the graphics card BIOS.

Although the above-mentioned graphics card performance control method can control the performance of the graphics card, it will only passively control the graphics card performance according to the temperature of the graphics card, and will not actively control the graphics card performance according to the scenario and needs. In many cases, performance control is performed only after the temperature of the device or graphics card is too high to reduce the temperature, which does not provide a very good experience for users. In addition, Dx only supports 5 levels of upper limit value for controlling the graphics card, and the adjustment range is relatively fixed. It is impossible to adjust the performance parameters of the graphics card according to the specific scenario, which results in some scenarios being unable to provide users with better performance. For example, in scenarios that require greater CPU performance (such as programming), adjusting the graphics card performance through Dx according to the graphics card temperature may result in a lower graphics card performance requirement, but still occupying a larger power consumption indicator, which results in devices such as notebooks being unable to provide sufficient CPU performance.

In addition, the commonly used performance control methods at present include directly setting the TPP&TGP&TDP values in the BIOS according to the conditions such as heat dissipation and performance when designing the device. The graphics card automatically adjusts the performance according to the TPP/TGP/TDP set values during operation, or when the game/GPU single baking/dual baking requires high GPU performance, the graphics card driver automatically adjusts the performance, but the TPP/TGP/TDP parameters will not change during this process. In other words, the CPU and graphics card performance parameters will not change according to the scene, but will only change according to the power consumption of the chip. This method cannot adapt to the CPU requirements in different scenes. Different performance requirements than graphics cards.

In addition, there is currently a method to control the graphics card performance by setting the TPP and TGP of the graphics card through the WMI interface. This method also directly sets the TPP, TGP and DB values, and will not dynamically adjust according to the current user scenario of the electronic device. It has a small scope of application, and the accuracy of graphics card performance control will be affected by the actual CPU power and is not stable.

Based on the above reasons, the embodiment of the present application provides a performance control method, which identifies the current scene of the device, sets the specific parameters or Dx values of TPP, TGP and/or TDP according to the specific scene when performance control is needed, so that the graphics card can perform performance control according to the current TPP, TGP and/or TDP parameters or Dx values, thereby providing more reasonable CPU and GPU performance according to the scene, which not only better meets the performance requirements of users in various scenes, but also can relatively improve the battery life of the device, thereby improving the user experience. The performance control method provided by the embodiment of the present application is described in detail below.

FIG2 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. It should be understood that the electronic device 100 shown in FIG2 is only an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. The various components shown in FIG2 may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.

The electronic device 100 may include: a processor 110, an internal memory 122, an external memory 121, an embedded controller (EC) 130, an independent graphics processor 140, a BIOS firmware flash memory 150, an antenna 1, a wireless communication module 160, a display screen 170, a fan 180, a keyboard 181, a temperature sensor 190, etc.

The processor 110 is, for example, a central processing unit (CPU), which may include one or more processing cores. The processor 110 may also include: a controller, a memory controller, a graphics processing unit (GPU, integrated graphics card), etc.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory or a register.

In some embodiments, the processor 110 may include an interface bus, which may include one or more interfaces. The interface may include a system management bus ("SMBus"), a low pin count (LPC) bus, a serial peripheral interface ("SPI"), a high-definition audio ("HDA") bus, a serial advanced technology attachment ("SATA") bus, a standardized interconnect (e.g., PCIe) and/or a universal serial bus (USB) interface, etc.

It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), etc. applied to the electronic device 100. In some embodiments, the antenna 1 of the electronic device 100 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology.

The electronic device 100 implements the display function through an independent graphics processor (i.e., independent graphics card or independent GPU) 140 or a graphics processor integrated in the processor 110 (i.e., integrated graphics card or integrated GPU), a display screen 170, and the processor 110. The graphics processor (GPU) is used to perform mathematical and geometric calculations for graphics rendering. The electronic device 100 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 170 is used to display interfaces, images, videos, etc. The display screen 170 includes a display panel.

The internal memory (or main memory) 120 may include a program storage area and a data storage area. The program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100, etc. In addition, the internal memory 120 may include a high-speed random access memory (RAM), such as a DDR (Double Data Rate) RAM, more specifically a DDR4 or DDR5 RAM. The internal memory (or main memory) 120 may be connected to the processor 110 in communication via a memory bus.

The external memory 121 is, for example, a solid state disk (“SSD”) or a hard disk drive (“HDD”) or a flash memory device, a universal flash storage (UFS), etc. The external memory 121 can be communicatively connected to the processor 110 via a serial advanced technology attachment (“SATA”) bus or a standardized interconnect (e.g., PCIe).

The embedded controller (EC) 130 is used to implement functions such as keyboard control, touchpad, power management, fan control, etc. The controller 130 can sample the CPU or GPU temperature through the temperature sensor 190, and then adjust the fan according to the algorithm based on the CPU or GPU temperature. The controller 130 can include independently running software stored in its own non-volatile medium. The temperature of the external temperature sensor read by the controller 130 is also stored in the internal RAM of the controller 130. The controller 120 can be connected and communicated with the processor 110 through, for example, an eSPI or LPC bus.

The independent graphics processor 140 is used to perform mathematical and geometric calculations for graphics rendering. The independent graphics processor 140 can enter a low-power sleep state when no 3D program is running. When the independent graphics processor 140 is asleep, the graphics rendering work of the electronic device 100 is completed by the graphics processor (i.e., integrated graphics card or integrated GPU) in the processor 110. The independent graphics processor 140 can be connected to the processor 110 through a standardized interconnect (e.g., PCIe). The independent graphics processor 140 can perform performance control according to the Dx parameters or TPP, TGP parameters of the graphics card.

The BIOS firmware flash memory 150 is used to store the BIOS firmware, which may be a traditional BIOS firmware or a UEFI-based BIOS firmware. The BIOS firmware flash memory 150 may be a ROM (read-only memory) or a Flash memory (flash memory). The BIOS firmware includes the mainboard BIOS firmware and the graphics card BIOS firmware.

The fan 180 is used to dissipate heat for the processor 110, the independent graphics processor 140, etc., so as to reduce the temperature of the components and ensure the operation of the device. The electronic device 100 may include one or more fans 180. For example, the electronic device 100 may arrange a fan near the processor 110 and a fan near the independent graphics processor 140.

The keyboard 181 is used for input by a user of the electronic device 100 .

The temperature sensor 190 is used to collect the temperature of the components of the electronic device 100, such as the processor 110, the internal memory 120, the independent graphics processor 140, etc. The electronic device 100 may include one or more temperature sensors 190. Exemplarily, for example, one or more temperature sensors 190 are arranged outside the processor 110, one or more temperature sensors are arranged outside the internal memory 120, and one or more temperature sensors 190 are arranged outside the independent graphics processor 140. The temperature sensor 190 can be connected to the processor 110 or the embedded controller (EC) 130 through, for example, a system management bus ("SMBus"), so as to send the collected temperature to the processor 110 or the embedded controller (EC) 130.

The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Windows system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

FIG. 3 is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

The layered architecture of the electronic device 100 divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces.

In some embodiments, the Windows system is divided into user state and kernel state. The user state includes the application layer and the subsystem dynamic link library. The kernel state is divided from bottom to top into the firmware layer, the hardware abstraction layer (HAL), the kernel and the driver layer, and the executive body.

As shown in Figure 3, the application layer includes applications such as music, video, games, office, performance control software, etc. The application layer also includes an environment subsystem, a scheduling engine, a system support process, a service process, etc. Among them, only some applications are shown in the figure, and the application layer can also include other applications, such as shopping applications, browsers, etc., which are not limited in this application.

The environment subsystem can present certain subsets of the basic executive system services to the application in a specific form, providing an execution environment for the application.

The scene recognition engine can identify the user scene in which the electronic device 100 is located, and determine a basic scheduling strategy (also referred to as a second scheduling strategy) that matches the user scene.

The scheduling engine can obtain the load condition of the electronic device 100, and determine the actual scheduling strategy that meets the actual operation condition of the electronic device 100 in combination with the load condition of the electronic device 100 and the above-mentioned basic scheduling strategy.

The performance control application can perform performance control on the CPU, GPU, etc. according to the user scenario of the electronic device 100. The performance control application can be an independent application, or a software module integrated with other applications (such as a computer manager), or can be integrated in a service or engine of an operating system.

The subsystem dynamic link library includes an API module, which includes Windows API, Windows native API, NVAPI, etc. Among them, Windows API and Windows native API can provide system call entry and internal function support for applications. The difference is that Windows native API is an API native to the Windows system. For example, Windows API may include user.dll and kernel.dll, and Windows native API may include ntdll, dll. Among them, user.dll is the Windows user interface interface, which can be used to perform operations such as creating windows and sending messages. kernel.dll is used to provide applications with an interface to access the kernel. ntdll.dll is an important Windows NT kernel-level file that describes the interface of the windows native NTAPI. When Windows starts, ntdl1.dll resides in a specific write-protected area in the memory, so that other programs cannot occupy this memory area.

The executive body includes the process manager, virtual memory manager, security reference monitor, I/O manager, Windows management instrumentation (WMI), power manager, operating system event driver (OsEventDriver) node, operating system to System on Chip (OS2SOC) node, etc.

The process manager is used to create and terminate processes and threads.

The Virtual Memory Manager implements "virtual memory". The Virtual Memory Manager also provides basic support for the Cache Manager.

The Security Reference Monitor enforces security policy on the local computer, protects operating system resources, and performs runtime object protection and monitoring.

The I/O manager performs device-independent input/output and further processes calls appropriate device drivers.

The power manager manages power state changes for all devices that support power state changes.

The system event driven node can interact with the kernel and driver layer, for example, interact with the graphics card driver, and after determining that there is a GPU video decoding event, report the GPU video decoding event to the scene recognition engine.

The system and chip driver nodes may be used by the scheduling engine to send adjustment information to the hardware device, for example, to send information for adjusting PL1 and PL2 to the CPU.

The kernel and driver layer include the kernel and device drivers.

The kernel is an abstraction of the processor architecture, isolating the executive body from the differences in the processor architecture to ensure the portability of the system. The kernel can perform thread scheduling and dispatching, trap handling and exception dispatching, interrupt handling and dispatching, etc.

Device drivers run in kernel mode and are interfaces between the I/O system and related hardware. Device drivers may include graphics card drivers, Intel DTT drivers, mouse drivers, audio and video drivers, camera drivers, keyboard drivers, etc. For example, a graphics card driver can drive the GPU to run, and an Intel DTT driver can drive the CPU to run.

HAL is a kernel-state module that can hide various hardware-related details, such as I/O interfaces, interrupt controllers, and multi-processor communication mechanisms, and provide a unified service interface for different hardware platforms running Windows, achieving portability on multiple hardware platforms. It should be noted that in order to maintain the portability of Windows, Windows internal components and user-written device drivers do not directly access the hardware, but call routines in HAL.

The firmware layer can include the basic input output system (BIOS). BIOS is a set of programs that are fixed to a read-only memory (ROM) chip on the computer motherboard. It stores the most important basic input and output programs of the computer, the self-test program after powering on, and the system self-starting program. It can read and write specific information of system settings from the complementary metal oxide semiconductor (CMOS). Its main function is to provide the lowest-level and most direct hardware settings and control for the computer.

The Intel DTT driver can send instructions to the CPU through the BIOS.

It should be noted that the embodiments of the present application are only illustrated using the Windows system as an example. In other operating systems (such as the Android system, the IOS system, etc.), as long as the functions implemented by each functional module are similar to those of the embodiments of the present application, the solutions of the present application can also be implemented.

It is understandable that the layers in the software structure shown in FIG3 and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer layers than shown in the figure, and each layer may include more or fewer components, which is not limited in the present application.

FIG. 4 is a schematic diagram showing the software and hardware workflow when the electronic device 100 schedules resources.

As shown in FIG4 , the scene recognition engine of the application layer includes a system probe module, a scene recognition module, and a basic strategy matching manager. The scene recognition module can interact with the system probe module and the basic strategy matching manager respectively. The scene recognition module can send a request for obtaining the probe status to the system probe module. The system probe module can obtain the operating status of the electronic device 100. For example, the system probe module can include a power status probe, a peripheral status probe, a process load probe, an audio and video status probe, a system load probe, and a system event probe.

Among them, the power state probe can subscribe to the power state event from the kernel state, and determine the power state according to the callback function fed back by the kernel state. The power state includes the battery (remaining) power, power mode, etc. The power mode may include alternating current (AC) and direct current (DC). For example, the power state probe can send a request to subscribe to the power state event to the OsEventDriver node of the executive layer, and the OsEventDriver node forwards the request to the power manager of the executive layer. The power manager can feed back the callback function to the power state probe through the OsEventDriver node.

The peripheral state probe can subscribe to peripheral events in the kernel state and determine the peripheral events according to the callback function fed back by the kernel state. Peripheral events include mouse wheel sliding events, mouse click events, keyboard input events, microphone input events, camera input events, etc.

The process load probe may subscribe to the process load in the kernel state, and determine the load of the process (eg, the first process) according to the callback function fed back by the kernel state.

The system load probe can subscribe to the system load in the kernel state and determine the system load based on the callback function fed back by the kernel state.

The audio and video status probe can subscribe to audio and video events in the kernel state, and determine the audio and video events currently existing in the electronic device 100 according to the callback function fed back by the kernel state. Audio and video events may include GPU decoding events, etc. For example, the audio and video status probe can send a request for subscribing to GPU decoding events to the OsEventDriver node of the executive layer, and the OsEventDriver node forwards the request to the graphics card driver of the kernel and driver layer. The graphics card driver can monitor the status of the GPU, and after monitoring that the GPU is performing a decoding operation, it feeds back a callback function to the audio and video status probe through the OsEventDriver node.

The system event probe can subscribe to system events in the kernel state and determine the system events based on the callback function fed back by the kernel state. System events may include window change events, process creation events, thread creation events, etc. For example, the system event probe can send a request to subscribe to the process creation event to the OsEventDriver node of the executive layer, and the OsEventDriver node forwards the request to the process manager. After creating the process, the process manager can feed back the callback function to the system event probe through the OsEventDriver node. For another example, the system event probe also sends a subscription focus window change event to the API module. The API module can monitor whether the focus window of the electronic device 100 changes, and when the focus window is monitored to change, it feeds back the callback function to the system event probe.

It can be seen that the system probe module subscribes to various events of the electronic device 100 in the kernel state, and then determines the running state of the electronic device 100 according to the callback function fed back by the kernel state, that is, obtains the probe state. After obtaining the probe state, the system probe module can feed back the probe state to the scene recognition module. After receiving the probe state, the scene recognition module can determine the user scene in which the electronic device 100 is located according to the probe state. The user scene may include a video scene, a game scene, an office scene, and a social scene. The user scene can reflect the user's current usage needs. For example, when the scene recognition engine identifies that the focus window is a window of a video application, it determines that the electronic device 100 is in a video scene, which means that the user needs to use a video application to watch and browse videos. For another example, when the scene recognition engine identifies that the focus window is a chat window of WeChat ^TM , it determines that the electronic device 100 is in a social scene. The scene recognition module can also send the user scene to the basic policy matching manager. The basic policy matching manager can determine the basic scheduling strategy (also referred to as the second scheduling strategy) according to the user scenario, and specifically refer to the description in S301 and S302 below. The basic policy matching manager can feed back the basic scheduling strategy to the scene recognition module. The scenario recognition module may send the basic scheduling strategy and user scenario to the scheduling engine of the application layer.

As shown in Figure 4, the scheduling engine includes a load controller, a chip strategy aggregator, and a scheduling executor. Among them, the load controller can receive the basic scheduling strategy and user scenario sent by the scenario recognition module. The load controller can also obtain the system load from the system probe module, and adjust the basic scheduling strategy according to the system load and user scenario to obtain the actual scheduling strategy (also referred to as the first scheduling strategy, please refer to the description in S310 below for details). The actual scheduling strategy includes the OS scheduling strategy and the first CPU power consumption scheduling strategy (also referred to as the first sub-strategy). Among them, the load controller can send the OS scheduling strategy to the scheduling executor, and the scheduling executor will make adjustments based on the OS scheduling strategy. The OS scheduling policy is used to adjust the process priority and I/O priority of the focus process. Exemplarily, the scheduling executor may send an instruction to adjust the process priority of the focus process to the process manager, and in response to the instruction, the process manager adjusts the process priority of the focus process. For another example, the scheduling executor may send an instruction to adjust the I/O priority of the focus process to the I/O manager, and in response to the instruction, the I/O manager adjusts the I/O priority of the focus process.

The load controller can also send the first CPU power consumption scheduling strategy to the chip strategy fusion device, and the chip strategy fusion device can obtain the second CPU power consumption scheduling strategy (also called the second sub-strategy, see the description in S317 to S325 below) based on the CPU chip platform type and the first CPU power consumption scheduling strategy. There are two main types of CPU chip platforms: (advanced micro devices, AMD) CPU and These two types of CPUs have different ways of adjusting CPU power consumption, so they need to be distinguished.

If the chip platform type of the CPU is AMD (also called the first type), the scheduling executor can send an instruction to adjust the EPP to the power manager to adjust the EPP of the CPU. In addition, the scheduling executor can also send an instruction to adjust PL1 and PL2 to the OS2SOC driver node to adjust the PL1 and PL2 of the CPU.

If the CPU chip platform type is The scheduling executor can send the second CPU power consumption scheduling policy to the Intel DTT driver through the WMI plug-in. The second CPU power consumption scheduling policy may include the minimum value of PL1, the maximum value of PL1, PL2, the duration of PL2 and EPP. The Intel DTT drives the CPU to run based on the second CPU power consumption scheduling policy.

The performance control method provided in the embodiment of the present application is mainly divided into two processes, namely: (1) determining the user scenario of the electronic device; and (2) determining the performance parameters of the electronic device according to the user scenario of the electronic device. The above two processes will be described below in conjunction with the accompanying drawings.

The following will take the electronic device in the video playback scenario as an example, and combine with Figure 5 to illustrate the interaction process of some modules in the electronic device shown in Figure 4. As shown in Figure 5, a performance control method provided by an embodiment of the present application determines the user scenario in which the electronic device is located as follows:

S501. The system probe module sends a request for subscribing to a process creation event to an OsEventDriver node.

As shown in Figure 5, the scene recognition engine includes a system probe module, and the system probe module includes a system event probe. In an embodiment of the present application, the system event probe can send a request to subscribe to a process creation event to an OsEventDriver node located at the executive layer. The request to subscribe to a process creation event can also be referred to as a first request.

In an optional implementation, the request for subscribing to a process creation event may carry a process name. That is, the scene recognition engine may only subscribe to the creation event of a specified process, reducing interference from creation events of irrelevant processes. For example, the specified process may be a process of a video application, a process of a game application, a process of an office application, a process of a social application, and so on. Of course, in other implementations, the scene recognition engine may not impose restrictions on the subscribed process creation events.

S502: The OsEventDriver node sends a request for subscribing to a process creation event to the process manager.

The request for the process creation event can refer to the description of S501, which will not be repeated here.

That is, the system event probe of the scene recognition engine can send a request to subscribe to the process creation event to the process manager through the OsEventDriver node.

It can be understood that the OsEventDriver node will register a callback with the process manager. The purpose of registering the callback is that after the process manager creates a process, the process creation event can be returned to the OsEventDriver node.

S503: The system probe module sends a request to subscribe to GPU decoding events to the OsEventDriver node.

Still as shown in Figure 4, the system probe module also includes an audio and video status probe. In the embodiment of the present application, the audio and video status probe of the system probe module can send a request to subscribe to GPU decoding events to the OsEventDriver node. The request to subscribe to GPU decoding events can also be called a third request.

S504. The OsEventDriver node sends a request to subscribe to GPU decoding events to the graphics card driver.

That is to say, the audio and video status probe of the scene recognition engine can send a request to subscribe to GPU decoding events to the graphics driver through the OsEventDriver node. Similarly, the OsEventDriver node can register a callback with the graphics driver. The purpose of registering this callback is that when the graphics driver monitors the GPU for decoding operations, it can return the GPU decoding event to the OsEventDriver node.

S505: The system probe module sends a request for subscribing to a focus window change event to the API module.

The API module may include a windows user interface implemented by user32.dll, which can be used to create a window. In an optional implementation, a system event probe of the system probe module may send a request to subscribe to a focus window change event to the windows user interface of the API module. The request to subscribe to a focus window change event may also be referred to as a second request.

Similarly, the system event probe can register a callback with the API module. The purpose of registering the callback is that when the API module (windows user interface interface) monitors the focus window change, the focus window change event can be returned to the system event probe.

The focus window is the window with focus, which is most likely the window that the user currently needs to use. Therefore, by monitoring the focus window, the user's usage needs can be determined. For example, if the focus window is the window of a video application, it indicates that the user needs to browse and play videos. For another example, if the focus window is the window of a game application, it indicates that the user needs to play games. By monitoring whether the focus window changes, it can be determined whether the user's needs have changed. For example, if the focus window changes from the window of a video application to the window of a game application, it indicates that the user's current need has changed from watching videos to playing games.

It should be noted that there is no strict order between the above S501, S503 and S505. They can be executed in sequence according to the order shown in FIG5, or they can be executed simultaneously, or they can be executed in the order of S503, S501, S505, S503, S505, S501, S505, S501, S503, or S505, S503, S501. Correspondingly, there is no strict order between S502, S504 and S506. As long as S502 is executed after S501, S504 is executed after S503 and S506 is executed after S505, no specific restrictions are made here.

S506: In response to receiving the user's operation of starting the video application, the video application sends a request to create a process to the process manager.

The create process request includes the storage address of the video application.

The video application can send a request to create a process to the process manager through the kernel32.dll interface and the Ntdll.dll interface of the API module (not shown).

S507: The process manager creates a video application process.

Specifically, the process manager can query the binary file of the video application program through the storage address. By loading the binary file of the video application program, an environment for process operation can be created to start the video application process.

The Windows operating system defines a single run of an application as a process. A process can have multiple threads. A window is an instance of a window structure, which is a graphical user interface (GUI). GUI) resources, a window is created by a thread, and a thread can own all windows it creates. In an embodiment of the present application, the electronic device runs a video application, and the process manager needs to create a process for the video application, that is, a video application process (that is, a first process). The video application process includes multiple threads, and the multiple threads include thread 1. Thread 1 can be used to create the main window of the video application, and the main window is a window that integrates all function keys of the video application.

S508: The process manager reports the process creation event to the OsEventDriver node.

Among them, the process creation event may include the name of the process created by the process manager. In the embodiment of the present application, the name of the process is the name of the video application process. Of course, if the process manager creates a process of other applications, the name of the process also corresponds to the name of the other application process.

As described above, the OsEventDriver node sends a request to the process manager to subscribe to the process creation event and registers a callback. Therefore, after creating the video application process, the process manager can report the process creation event to the OsEventDriver node.

S509. The OsEventDriver node reports the process creation event to the system probe module.

The description of the process creation event is described in S508 and will not be repeated here.

In the embodiment of the present application, the OsEventDriver node may report the process creation event to the system event probe of the system probe module.

S510: The system probe module sends a process creation event to the scene recognition module.

S511 . In response to the calling request of thread 1 , the API module creates window 1 .

After the process manager creates the video application process, thread 1 of the video application process actively calls the windows user interface interface of the API module to create window 1. Exemplarily, as shown in (a) of FIG. 6 , the electronic device can display window 601, which can be a desktop, or can also be called a main interface. The window 601 includes an icon 602 of the video application. The electronic device can receive an operation of a user clicking on the icon 602 of the video application, and in response to the operation, as shown in (b) of FIG. 6 , the electronic device displays window 603 (i.e., window 1, or can also be called a first window). In the above process, the focus window changes from the original window 601 to window 603.

S512: The API module reports the focus window event to the system probe module.

In an embodiment of the present application, after the windows user interface of the API module creates window 1, the name of the first process (i.e., the focus process) and the name of the second process can be obtained. The first process is the process corresponding to the current focus window (i.e., window 1), and the second process is the process corresponding to the previous focus window (e.g., window 2). Exemplarily, the process corresponding to window 1 is a video application process (first process), and the name of the process is, for example, hlive.exe, and the process corresponding to window 2 is a process of the windows program manager (second process), and the name of the process is, for example, explorer.exe. Since the name of the first process is inconsistent with the name of the second process, the API module determines that the focus window has changed, and reports the focus window event to the system event probe of the system probe module. Among them, the focus window change event includes the name of the first process (i.e., the focus process). Exemplarily, the first process is a video application process, and the focus window change event carries the name of the video application process.

It should be noted that, if the electronic device has already started the video application, the electronic device does not need to execute S506 to S511. After the system probe module sends a request to subscribe to the focus window change event to the API module, if the user switches the focus window to the window of the video application, the API module can also detect the focus window change and report the focus window event to the system probe module.

S513: The system probe module sends a focus window event to the scene recognition module.

S514: The scene recognition module determines that the type of the first process is a video type.

The electronic device may be pre-configured with an application list, and the scene recognition module may query whether the application list includes the first process. If the application list includes the first process, the scene recognition module may determine the type of the first process. The application list includes the process name of each application and the type of the application. Exemplarily, the application list may be as shown in Table 1:

Table 1

For example, if the name of the first process is hlive.exe, the scene recognition module can determine that the type of the first process is video. For another example, if the name of the first process is wechat.exe, the scene recognition module can determine that the type of the first process is social. It should be noted that the above Table 1 is only an example. In fact, Table 1 can also include process names of more applications and their types.

It should be noted that the purpose of this step is to preliminarily determine the user scenario in which the electronic device is located. The user scenario in which the electronic device is located may include video scenarios, game scenarios, social scenarios, office scenarios, browser scenarios, etc. Among them, the video scenario may further include video playback scenarios and video browsing scenarios. The social scenario may further include text chat scenarios, voice chat scenarios, video chat scenarios, etc. The office scenario may further include document editing scenarios, document browsing scenarios, video conferencing scenarios, etc. The browser scenario may include web browsing scenarios and video playback scenarios, etc.

In this step, the type of user scenario in which the electronic device is located can be determined by the type to which the first process belongs. For example, if it is determined that the type to which the first process belongs is a video type, it can be determined that the electronic device is in a video scenario; for another example, if it is determined that the type to which the first process belongs is a game type, it can be determined that the electronic device is in a game scenario. In order to further analyze user needs, the scene recognition module can further combine other parameters (for example, peripheral events, GPU operating status, etc.) to analyze the specific scenario in which the electronic device is located, so as to achieve a more accurate analysis result. The specific content is described later and will not be described here.

S515: In response to receiving the user's operation of playing the video, the video application sends a video playing instruction to the API module.

Specifically, the video application may send the video play instruction to the DirectX API of the API module. The video play instruction may include the cache address of the video.

S516. The API module reads the video file.

The API module can read the corresponding video file according to the cache address carried in the video playback instruction.

S517. The API module sends a decoding instruction to the graphics card driver.

S518: The graphics card driver sends a startup instruction to the GPU.

S519: GPU performs decoding.

Specifically, the GPU can decode the video file through the GPU video processing engine.

S520. The GPU reports a decoding event to the graphics card driver.

S521. The graphics card driver reports a decoding event to the OsEventDriver node.

S522. The OsEventDriver node reports the decoding event to the system probe module.

Specifically, the OsEventDriver node reports the decoding event to the audio and video status probe of the system probe module.

S523: The system probe module sends a decoding event to the scene recognition module.

S524. The scene recognition module sends instruction 1 to the system probe module.

Instruction 1 instructs the system probe module to obtain the GPU occupancy rate of the first process. The instruction 1 may carry the name of the first process.

S525. The system probe module sends a request to the process manager to obtain the GPU occupancy rate of the first process.

The request for obtaining the GPU occupancy rate of the focus process may include the name of the first process.

In an optional implementation, the audio and video status probe of the system probe module may send a request for obtaining the GPU occupancy rate of the first process to the process manager.

S526: The process manager collects the GPU occupancy rate of the first process.

Specifically, the process manager can collect the GPU occupancy rate of the first process through the graphics kernel interface of the graphics card driver.

S527: The process manager sends the GPU occupancy rate of the first process to the system probe module.

The process manager may send the GPU occupancy rate of the first process to the audio and video status probe of the system probe module.

S528. The system probe module sends the GPU occupancy rate of the first process to the scene recognition engine.

S529: The scene recognition module determines whether the GPU occupancy rate of the first process is greater than 0.

If the GPU occupancy rate of the first process is greater than 0, S130 is executed.

Through the GPU occupancy rate of the first process, it can be determined whether the first process uses the GPU during operation. If the GPU occupancy rate of the first process is greater than 0, it can be considered that the first process uses the GPU during operation; if the GPU occupancy rate of the first process is 0, it indicates that the first process does not use the GPU during operation.

S530: The scene recognition module sends instruction 2 to the system probe module.

Instruction 2 instructs the system probe module to obtain the GPU engine of the first process. The instruction 2 may carry the name of the first process.

S531. The system probe module sends a request to the process manager to obtain the GPU engine of the first process.

The audio and video status probe of the system probe module may send a request to the process manager to obtain the GPU engine of the first process. The request to obtain the GPU engine of the first process includes the name of the first process.

The GPU engine includes a GPU 3D engine, a GPU copy engine, a GPU video encode engine, and a GPU video processing engine. Among them, the GPU 3D engine is mainly responsible for processing 2D or 3D graphics. The GPU copy engine is mainly used to transmit data. The GPU video encode engine is mainly used for encoding operations. The GPU video processing engine mainly performs decoding operations. In some embodiments, the GPU video processing engine can also be replaced by the GPU video decode engine.

S532: The process manager obtains the GPU engine of the first process.

Specifically, the process manager can obtain the GPU engine of the first process through the graphics kernel interface of the graphics card driver.

S533: The process manager sends a message 1 to the system probe module, where the message 1 indicates that the GPU engine of the first process is a GPU video processing engine.

Specifically, the process manager may send the message to the audio and video status probe of the system probe module, and then the audio and video status forwards the message to the scene recognition module.

S534. The system probe module sends message 1 to the scene recognition module.

S535. The scene recognition module determines whether the GPU engine of the first process is a GPU video processing engine.

If the GPU engine of the first process is a GPU video processing engine, execute S529; if the GPU engine of the first process is not a GPU video processing engine, execute S530.

In step S514, the scene recognition engine has determined that the type to which the first process belongs is a video class, that is, it can be determined that the electronic device is in a video scene. Through step S535, the scene recognition engine can determine the specific operations performed by the first process through the GPU, and then determine the specific operations of the user using the video application. For example, if the GPU engine of the first process is a GPU video processing engine, it means that the first process is using the GPU for decoding operations, and it can be considered that the user is using the video application to play the video. For another example, if the GPU engine of the first process is not a GPU video processing engine, it means that the first process is not using the GPU for decoding operations, then the user is most likely browsing video resources on the video application and has not yet played the video.

S536: The scene recognition module determines that the user scene is a video playback scene according to the process information of the first process.

The process information of the first process includes information such as the name of the first process, the application type to which the first process belongs, the GPU occupancy rate of the first process, and the GPU engine used by the first process.

Based on the above content, it can be seen that if the type of the first process (focus process) is video type, the GPU occupancy of the first process is greater than 0, and the GPU engine of the first process is a GPU video processing engine, it can be determined that the electronic device is in a video playback scene.

It should be noted that the above S501 to S536 are only described by taking the video playing scene of the electronic device in the video scene as an example. In fact, the electronic device can also be in other user scenes (for example, game scene, office scene, social scene, video browsing scene, programming scene, etc.).

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the game category, the power mode of the CPU is changed to game mode (game mode), the GPU occupancy rate of the first process is greater than 0, and the GPU engine of the first process is a GPU 3D engine, it can be determined that the electronic device is in a game scene.

The power status probe of the system probe module may send a request to the power manager to subscribe to the power mode change event. The power manager may report the power mode change event to the power status probe of the system probe module when the power module is switched to game mode. In this way, the scene recognition engine may determine whether the power mode of the CPU is game mode through the power mode change event.

In addition, the process of the scene recognition engine obtaining the type of the first process can refer to S501, S502, S505, S506-S514 in Figure 5, and the process of the scene recognition engine determining whether the GPU occupancy rate of the first process is greater than 0 and whether the GPU engine of the first process is a GPU 3D engine can refer to S524-S535. The difference is that the video application is replaced with a game application, which will not be repeated here.

Next, in conjunction with FIG. 7, a brief description is given of the process of an electronic device determining the user scenario in which it is located when it is in an office scenario. It should be noted that the principle and process of the flowchart shown in FIG. 7 are basically the same as those of the flowchart shown in FIG. 5. Only the differences between the two are specifically described below, and the similarities are not repeated. For details, please refer to the description of the relevant steps in FIG. 5. FIG. 7 shows a performance control method provided in an embodiment of the present application, and the process of determining the user scenario in which the electronic device is located is as follows:

S701. The system probe module sends a request to subscribe to a process creation event to an OsEventDriver node.

S702. The OsEventDriver node sends a request to subscribe to a process creation event to the process manager.

S703: The system probe module sends a request for subscribing to peripheral events to the OsEventDriver node.

As shown in Figure 4, the system probe module also includes a peripheral status probe. In the embodiment of the present application, the peripheral status probe of the system probe module can send a request to subscribe to peripheral events to the OsEventDriver node. The request to subscribe to peripheral events can also be called a fourth request.

Among them, peripheral events include mouse wheel sliding, mouse clicking, keyboard input, camera input, microphone input and other events.

S704. The OsEventDriver node sends a request for subscribing to peripheral events to the peripheral driver.

It should be noted that the peripheral driver is a general term for drivers of all peripherals, for example, it may include a mouse driver, a keyboard driver, a camera driver, a microphone driver, etc.

S705: The system probe module sends a request for subscribing to a focus window change event to the API module.

S706: In response to receiving the user's operation of starting the office application, the office application sends a request for creating an office application process to the process manager.

The request for creating an office application process may include a storage address of the office application program.

S707: The process manager creates an office application process.

Specifically, the process manager can query the binary file of the office application through the storage address. By loading the binary file of the office application, an environment for process operation can be created to start the video application process. In addition, the office application process includes thread 2, which can be used to create the main window of the office application.

S708: The process manager reports the process creation event to the OsEventDriver node.

S709. The OsEventDriver node reports the process creation event to the system probe module.

The process creation event carries the name of the office application process.

S710: The system probe module sends a process creation event to the scene recognition module.

S711. In response to the call request of thread 2, the API module creates an office application window.

S712. The API module reports the focus window event to the system probe module.

Among them, the focus window event carries the name of the first process (focus process). It can be understood that in the embodiment of the present application, the first process is the office application process.

S713: The system probe module sends a focus window event to the scene recognition module.

S714: The scene recognition module determines that the type of the first process is office type.

For example, if the name of the first process is word.exe, it can be determined that the type of the first process is office type.

S715: In response to the user's operation on the peripheral device, the peripheral device driver detects a peripheral device event.

S216: The peripheral driver reports the peripheral event to the OsEventDriver node.

S717. The OsEventDriver node sends a peripheral event to the system probe module.

S718. The system probe module sends a peripheral event to the scene recognition module.

S719: The scene recognition module determines a user scene according to the peripheral event and the type of the first process.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the office category, and the peripheral event is a mouse wheel sliding event or a click event, it can be determined that the electronic device is specifically in a document browsing scene in an office scene. If the electronic device belongs to the office category and does not receive a mouse wheel sliding event, a mouse click event, or a keyboard input event within a preset time (for example, 10 seconds) after receiving a keyboard input event, it can be determined that the electronic device is specifically in a document browsing scenario under an office scenario.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the office category and receives a keyboard input event, it can be determined that the electronic device is specifically in a document editing scene in an office scenario.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the office type, and receives a camera input event (i.e., the camera is on and there is a video stream input), it can be determined that the electronic device is specifically in a video conferencing scene in an office scenario.

The electronic device can also be in a social scene. The social scene includes three specific scenes, namely: text chat scene, voice chat scene and video chat scene. The principle of judging whether the electronic device is in a social scene is similar to the principle of judging whether the electronic device is in an office scene. We will not go into details here. The following only explains the conditions that need to be met to judge whether the electronic device is in a social scene.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the social category and receives a keyboard input event, it can be determined that the electronic device is specifically in a text chat scene under a social scene.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) is social, and a microphone input event is received and the camera is in an off state, it can be determined that the electronic device is specifically in a voice chat scene in a social scene.

In an optional implementation, if the scene recognition engine determines that the type of the first process (focus process) belongs to the social category, and receives a microphone input event and a camera input event, it can be determined that the electronic device is specifically in a video chat scene under a social scenario.

The above content explains how to identify the user scenario of the electronic device. After determining the user scenario of the electronic device, the electronic device can also determine whether performance regulation is needed according to the user scenario. When performance regulation is needed, the specific parameter values or Dx values of TPP, TGP and/or TDP are set according to the user scenario, so that the graphics card performs performance regulation according to the current TPP, TGP and/or TDP parameters or Dx values, thereby providing more reasonable CPU and GPU performance according to the scenario, which not only better meets the performance requirements of users in various scenarios, but also can relatively improve the battery life of the device, thereby improving the user experience.

FIG8 is a flow chart of a performance control method provided in an embodiment of the present application.

As shown in FIG8 , the performance control method provided in the embodiment of the present application specifically includes:

Step S801: The scene recognition engine determines the user scene of the electronic device and sends the scene information to the performance control application.

The scene information is used to indicate the user scene in which the electronic device is located. Exemplarily, the electronic device may pre-assign unique identifiers to different user scenes, and the scene information may include the unique identifier of the user scene. For example, the identifier (e.g., V01) may indicate that the electronic device is in a video playback scene. For another example, the identifier (e.g., V02) may indicate that the electronic device is in a video browsing scene.

Regarding the process of the scene recognition module determining the user scene in which the electronic device is located, please refer to S501 to S536 for details, which will not be repeated here.

Step S802: The performance control application determines parameter values of performance parameters according to scenario information.

The performance parameter includes a first performance parameter and a second performance parameter. The first performance parameter includes at least one of the TDP power consumption of the CPU, the TGP power consumption of the GPU, the TPP power consumption of the GPU, and the DB power consumption of the GPU. The second performance parameter includes the Dx value of the GPU.

Exemplarily, in an embodiment of the present application, the performance requirements of various user scenarios can be predetermined through testing, such as determining the performance required for an office scenario through testing, and determining the parameter value of the first performance parameter in the office scenario based on the performance, such as determining the specific parameter values of the TDP power consumption of the CPU, the TGP power consumption of the GPU, the TPP power consumption of the GPU, and the DB power consumption of the GPU.

For example, in an embodiment of the present application, the performance requirements in various scenarios can be determined by establishing a user dynamic test model. The dynamic test model can be used to determine the CPU performance, GPU performance, etc. when the electronic device runs various types of applications, thereby determining the performance requirements of the electronic device in various scenarios based on these data, and then determining the specific values of the first performance parameters in various scenarios based on the performance requirements.

By adopting different first performance parameters in various scenarios, the electronic device can reduce the power consumption of the device while ensuring the smooth operation of the current application. Exemplarily, for example, when the electronic device is in an office scene, because the performance requirements are low, lower TGP, TDP, TPP and DB values can be set to ensure the smooth operation of office applications while reducing the power consumption of the device and extending the battery life of the device. When the electronic device is in a game scene, a performance test scene, or a 3D rendering scene, the GPU performance requirements are large, so the TPP, DB, and TGP values can be large, so that the GPU can provide higher performance to meet the game operation requirements. When the electronic device is in a programming scene, the CPU performance requirements are large, and the GPU needs to have a small performance, so the TPP can be large, and the TGP and DB values can be small, so as to meet the programming requirements and reduce the power consumption of the device. In other words, in an embodiment of the present application, the parameter value of the first performance parameter is dynamically adjusted according to the scene in which the electronic device is located, so as to ensure the smooth operation of the application, reduce the power consumption of the device, and extend the battery life of the device. And compared with the current electronic device factory setting TDP, TGP or TPP value control method, it can better meet the performance requirements of the application, reasonably allocate CPU power consumption and GPU power consumption according to specific applications, and improve user experience.

It should be understood that for electronic devices, TPP generally has an upper limit value based on processor performance and heat dissipation design. In the embodiment of the present application, the specific values of TPP, TDP, and TGP set according to the electronic device are set within the TPP upper limit value. For example, if the maximum TPP of the electronic device is 90W, TPP can be set to 30W in a scene with low performance requirements. In a scene with large performance requirements, TPP can be set to a larger value such as 60W, 70W, or even 90W. And when the CPU performance requirement is large, TDP is large, and when the GPU performance requirement is large, TGP is large. Compared with the current performance control method based on TGP, TDP, and TPP, CPU and GPU power consumption can be allocated more flexibly. This is because the current control method generally directly sets TPP to, for example, 60W, TDP to 25W, and TGP to 35W, and the processor adjusts the performance according to the needs based on TPP, TGP, and TDP. This method cannot reasonably allocate CPU and GPU power consumption as needed because TDP and TGP have been set. By adopting the method of this embodiment, in a scenario where the GPU performance requirement is greater and the CPU performance requirement is smaller, the TGP can be set to 40 W and the TDP can be set to 20 W, which can better meet the performance requirements of the application.

It should also be understood that generally electronic devices are configured with a balanced mode and a performance mode, and the upper limits of performance parameters are different in the performance mode and the balanced mode. When the electronic device is in the performance mode, the parameter value of the first performance parameter in each user scenario is set within the upper limit of the first performance parameter in the performance mode. When the electronic device is in the balanced mode, the parameter value of the first performance parameter in each user scenario is set within the upper limit of the first performance parameter in the balanced mode. For example, if the TGP upper limit is 50W in performance mode and 30W in balanced mode, the TGP value of each user scenario is set within the upper limit of 50W in performance mode and within the upper limit of 30W in balanced mode.

Further, exemplarily, in an embodiment of the present application, the performance requirements of various user scenarios can be pre-determined by testing, for example, the performance required for an office scenario can be determined by testing, and the parameter value of the second performance parameter in the office scenario can be determined based on the performance. By adjusting the first performance parameter, the performance of the GPU can be adjusted more finely to provide a more reasonable performance for the GPU. By adjusting the second performance parameter, the GPU performance can be adjusted more significantly or quickly to quickly reduce (or increase) the GPU performance.

It should be noted that in the embodiment of the present application, the first performance parameter or the second performance parameter can be adjusted as needed according to the requirements of the user scenario.

In an optional implementation, Dx is set to D1 (maximum GPU power consumption) by default, and when the user scenario changes, the GPU performance is adjusted by adjusting the first performance parameter.

In an optional implementation, when the GPU performance required by the user scenario is very small, the Dx value can be adjusted to D4 or D5 to directly limit the GPU performance to a smaller value, thereby extending the battery life of the device.

In an optional implementation, when the performance requirement of the current user scenario increases relative to the performance requirement of the previous user scenario, the device provides greater GPU and CPU performance by adjusting the first performance parameter.

In an optional embodiment, when the remaining battery power of the electronic device is insufficient, for example, less than a set percentage (e.g., less than 20%), the Dx value is adjusted to D4 or D5 to directly limit the GPU performance to a smaller value, thereby extending the battery life of the device.

In an optional embodiment, when the temperature of the electronic device is too high, for example, greater than a set threshold (for example, greater than 90°C), the Dx value is adjusted to D4 or D5 to directly limit the GPU performance to a smaller value, thereby extending the battery life of the device.

It should be noted that the temperature of the electronic device includes the CPU temperature, GPU temperature, motherboard temperature, etc., and the over-high temperature of the electronic device means that one or more of the CPU temperature, GPU temperature, motherboard temperature, etc. are too high.

Step S803: the performance control application sends the parameter value of the performance parameter to the BIOS through the WMI interface.

After the parameter value of the performance parameter is determined in the aforementioned step S802, the performance control application calls the WMI interface to send the parameter value of the performance parameter to the BIOS.

Step S804: BIOS writes the parameter value of the performance parameter into the location indicated by ACPI, and notifies the GPU driver to read the parameter value of the performance parameter.

Exemplarily, ACPI specifies the storage location in the internal memory (i.e., the memory) for storing the first performance parameter and the second performance parameter. After the BIOS obtains the parameter values of the first performance parameter and the second performance parameter, it modifies the performance parameter at the storage location to the latest value, and then notifies the GPU driver to read the latest performance parameters of the graphics processor.

The storage location of the first performance parameter and the storage location of the second performance parameter may be the same or different.

Step S805: The GPU driver reads the parameter value of the performance parameter, and adjusts the performance of the GPU according to the parameter value of the performance parameter.

Specifically, after the BIOS modifies the value of the performance parameter of the graphics processor, an SCI interrupt is generated. After receiving the SCI interrupt (ie, event notification), the graphics driver calls the graphics control method (the graphics control method defined in ACPI) to read the current value of the performance parameter of the graphics processor.

After the performance parameters are read, the performance of the graphics processor is regulated according to the performance parameters. For example, after the current value of Dx is read, the graphics card performance is controlled according to the power consumption corresponding to the current value of Dx. For example, if the current Dx value is D3 and the corresponding graphics card power consumption is 15W, the GPU driver controls the graphics card to limit its maximum power consumption to 15W. For another example, after the current values of TGP, TDP, TPP, and DB are read, the graphics card performance is controlled according to the current values of TGP, TDP, TPP, and DB.

It should be noted that when controlling the graphics card performance according to the current values of TGP, TDP, TPP, and DB, the GPU driver also communicates with the CPU driver to obtain the current CPU power consumption, and adjusts the graphics card performance according to the current TGP, TDP, TPP, and DB values.

For example, if the current TGP is 40W, TDP is 30W, TPP is 70W, and DB is 15W, the GPU driver can limit the GPU power consumption to between 25W (40-15) and 55W (40+15) according to the actual power consumption of the CPU. That is, when the actual power consumption of the CPU is small, for example, the actual power consumption of the CPU is 15W, the GPU power consumption can be adjusted within 55W, that is, a maximum GPU power consumption of 55W can be provided. For another example, when the actual power consumption of the CPU is 30W, the GPU power consumption can be adjusted within 25W, that is, a maximum GPU power consumption of 25W can be provided, which can ensure sufficient CPU performance.

The performance control method provided in the embodiment of the present application is described below by taking a specific application as an example with reference to FIG. 9 and FIG. 10 .

FIG. 9 is an example control process of the performance control method provided in an embodiment of the present application.

As shown in FIG9 , the exemplary control process of the performance control method provided in the embodiment of the present application includes:

Step S901, in response to an operation for starting a first application, before starting the first application, a first performance parameter of the electronic device is a first parameter value.

Exemplarily, the first application is, for example, a programming application, such as various programming applications.

The first performance parameter includes at least one of TDP power consumption of the CPU, TGP power consumption of the GPU, TPP power consumption of the GPU, and DB power consumption of the GPU.

The first parameter value may be a parameter set including specific values of TDP, TPP, TGP, and DB. For example, the first parameter value may be TDP30W, TPP70W, TGP40W, and DB15W. By reducing TGP and DB, GPU performance may be effectively improved, thereby enabling the device to provide sufficient CPU performance.

Step S902: The scene recognition engine determines that the electronic device is in a first user scene according to the first application.

Exemplarily, the first user scenario is a programming scenario. For details about the process of the scenario recognition module determining the user scenario of the electronic device, please refer to S501 to S536, which will not be described in detail here.

Step S903: The scene recognition engine determines to send the first scene information to the performance control application.

Exemplarily, the electronic device may pre-assign unique identifiers to different user scenarios, and the scenario information may include the unique identifier of the user scenario.

Step S904: At a first time point, the performance control application adjusts the first performance parameter to a second parameter value according to the first scenario information, where the second parameter value is different from the first parameter value.

The second parameter value may be a parameter set including specific values of TDP, TPP, TGP, and DB. The second parameter value is different from the first parameter value, which means that the corresponding value of at least one parameter in the first parameter value and the second parameter value is different. For example, the TGP value in the first parameter value is different from the TGP value in the second parameter value.

Exemplarily, the second parameter value is, for example, TDP30W, TPP60W, TGP10W, DB5W.

By reducing TGP and DB, GPU performance can be effectively utilized, thereby allowing the device to provide sufficient CPU performance.

Step S905: the performance control application sends the second parameter value to the BIOS through the WMI interface.

Step S906: BIOS writes the second parameter value into the location indicated by ACPI, and notifies the GPU driver to read the second parameter value.

Specifically, the BIOS writes the second parameter value into the storage location of the first performance parameter indicated by ACPI, and notifies the GPU driver to read the second parameter value.

Step S907: The GPU driver reads the second parameter value and adjusts the performance of the GPU according to the second parameter value.

The process of the GPU reading the second parameter value is described in S805 and will not be repeated here.

Step S908: starting a second application in response to the user operation.

Exemplarily, the second application is, for example, a game application, such as a 3A large-scale game.

Step S909: The scene recognition engine determines that the electronic device is in a second user scene according to the second application.

Exemplarily, the second user scenario is a game scenario. For details about the process of the scenario recognition module determining the user scenario in which the electronic device is located, refer to S501 to S536, which will not be described in detail here.

Step S910: The scene recognition engine determines to send the second scene information to the performance control application.

Step S911: at a second time point, the performance control application adjusts the first performance parameter to a third parameter value according to the second scenario information, where the third parameter value is different from the second parameter value.

The third parameter value may be a parameter set including specific values of TDP, TPP, TGP, and DB. The third parameter value is different from the second parameter value, which means that the corresponding value of at least one parameter in the third parameter value and the second parameter value is different. For example, the TGP value in the third parameter value is different from the TGP value in the second parameter value.

Exemplarily, the third parameter value is, for example, TDP30W, TPP80W, TGP50W, and DB15W. By increasing TGP and DB, the electronic device can provide sufficient GPU performance and improve the gaming experience.

Step S912: The performance control application sends the third parameter value to the BIOS through the WMI interface.

Step S913, BIOS writes the third parameter value into the location indicated by ACPI, and notifies the GPU driver to read the second parameter value.

Specifically, the BIOS writes the third parameter value into the storage location of the first performance parameter indicated by ACPI, and notifies the GPU driver to read the third parameter value.

Step S914: The GPU driver reads the third parameter value and adjusts the performance of the GPU according to the third parameter value.

The process of the GPU reading the third parameter value is described in S805 and will not be repeated here.

FIG. 10 is another example control process of the performance control method provided in an embodiment of the present application.

As shown in FIG10 , the exemplary control process of the performance control method provided in the embodiment of the present application includes:

Step S1001: in response to an operation for starting a third application, before starting the third application, the second performance parameter of the electronic device is a fourth parameter value.

Exemplarily, the third application is, for example, an office application, such as various office software, such as Word.

The second performance parameter includes a Dx value of the GPU. Exemplarily, the fourth parameter value is, for example, D1.

Step S1002: The scene recognition engine determines that the electronic device is in a third user scene based on a third application.

Exemplarily, the third user scenario is an office scenario. For details about the process of the scenario recognition module determining the user scenario in which the electronic device is located, refer to S501 to S536, which will not be described in detail here.

Step S1003: The scene recognition engine determines to send the third scene information to the performance control application.

Step S1004: At a third time point, the performance control application adjusts the second performance parameter to a fifth parameter value according to the third scenario information, where the fifth parameter value is different from the fourth parameter value.

Exemplarily, the fifth parameter value is, for example, D4 or D5. In office scenarios, the GPU performance requirement is relatively low, so the GPU performance can be directly limited by adjusting the Dx value to improve the device battery life.

Step S1005: the performance control application sends the fifth parameter value to the BIOS through the WMI interface.

Step S1006, BIOS writes the fifth parameter value into the location indicated by ACPI, and notifies the GPU driver to read the fifth parameter value.

Specifically, the BIOS writes the fifth parameter value into the storage location of the second performance parameter indicated by ACPI, and notifies the GPU driver to read the fifth parameter value. The storage location of the second performance parameter can be the same as or different from the storage location of the first performance parameter.

Step S1007: The GPU driver reads the fifth parameter value and adjusts the performance of the GPU according to the fifth parameter value.

The process of the GPU reading the fifth parameter value is described in S805 and will not be repeated here.

Step S1008: starting a fourth application in response to the user operation.

For example, the fourth application is a game application, such as a 3A large game

Step S1009: The scene recognition engine determines that the electronic device is in a fourth user scene based on the fourth application.

Exemplarily, the fourth user scenario is a game scenario. For details about the process of the scenario recognition module determining the user scenario in which the electronic device is located, refer to S501 to S536, which will not be described in detail here.

Step S1010: The scene recognition engine determines to send fourth scene information to the performance control application.

Step S1011, at a fourth time point, the performance control application adjusts the second performance parameter to a sixth parameter value according to fourth scenario information, where the sixth parameter value is different from the fifth parameter value.

Exemplarily, the sixth parameter value is, for example, D1.

Step S1012: the performance control application sends the sixth parameter value to the BIOS through the WMI interface.

Step S1013, BIOS writes the fifth parameter value into the location indicated by ACPI, and notifies the GPU driver to read the fifth parameter value.

Specifically, the BIOS writes the fifth parameter value into the storage location of the second performance parameter indicated by ACPI, and notifies the GPU driver to read the fifth parameter value.

Step S1014: The GPU driver reads the fifth parameter value and adjusts the performance of the GPU according to the fifth parameter value.

It is understandable that in order to implement the above functions, the electronic device includes hardware and/or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed in this article, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered Beyond the scope of this application.

In one example, FIG11 shows a schematic block diagram of an apparatus 300 according to an embodiment of the present application. The apparatus 300 may include: a processor 301 and a transceiver/transceiver pin 302 , and optionally, a memory 303 .

The components of the device 300 are coupled together via a bus 304, wherein the bus 304 includes a power bus, a control bus, and a status signal bus in addition to a data bus. However, for the sake of clarity, all buses are referred to as bus 304 in the figure.

Optionally, the memory 303 may be used for the instructions in the aforementioned method embodiment. The processor 301 may be used to execute the instructions in the memory 303, and control the receiving pin to receive a signal, and control the sending pin to send a signal.

The apparatus 300 may be the electronic device or a chip of the electronic device in the above method embodiment.

Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

The steps performed by the parameter monitoring method provided in the above embodiment of the present application may also be performed by a chip system included in the electronic device 100, wherein the chip system may include a processor. The chip system may be coupled to a memory so that when the chip system is running, the computer program stored in the memory is called to implement the steps performed by the above electronic device 100. The processor in the chip system may be an application processor or a processor other than an application processor.

As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

A performance control method is characterized in that it is applied to an electronic device, wherein the electronic device includes a central processing unit (CPU) and a graphics processing unit (GPU), and the method includes:

In response to a user operation, a first application is started. Before the first application is started, a first performance parameter of the electronic device is a first parameter value, and the first performance parameter includes at least one of a TDP power consumption of the CPU, a TGP power consumption of the GPU, a TPP power consumption of the GPU, and a DB power consumption of the GPU;

After starting the first application, at a first time point, a first performance parameter of the electronic device is adjusted to a second parameter value, and the second parameter value is different from the first parameter value;

In response to a user operation, closing the first application and starting a second application;

After starting the second application, at a second time point, the first performance parameter of the electronic device is adjusted to a third parameter value, and the third parameter value is different from the second parameter value.
The performance control method according to claim 1, characterized in that the method further comprises:

In response to a user operation, a third application is started, and before the third application is started, a second performance parameter of the electronic device is a fourth parameter value, and the second performance parameter includes a Dx value of the GPU;

After starting the third application, at a third time point, adjusting the second performance parameter of the electronic device to a fifth parameter value, the fifth parameter value being different from the fourth parameter value;

In response to a user operation, closing the third application and starting a fourth application;

After starting the fourth application, at a fourth time point, the second performance parameter of the electronic device is adjusted to a sixth parameter value, and the sixth parameter value is different from the fifth parameter value.
The performance control method according to claim 1, characterized in that the method further comprises:

Before a fifth time point, a second performance parameter of the electronic device is a seventh parameter value, the second performance parameter includes a Dx value of the GPU, and the fifth time point is after the first time point and/or the second time point;

At a fifth time point, adjusting the second performance parameter of the electronic device to an eighth parameter value, wherein the eighth parameter value is different from the seventh parameter value;

The remaining battery power of the electronic device at the fifth time point is less than the remaining battery power at the first time point and/or the second time point, and the electronic device is not plugged in at the fifth time point; or

The temperature of the electronic device at the fifth time point is greater than the temperature at the first time point and/or the second time point.
The performance control method according to any one of claims 1 to 3, characterized in that the method further comprises:

Determining a user scenario of the electronic device according to the first application, and determining a value of the second parameter according to the user scenario of the electronic device;

The user scenario of the electronic device is determined according to the second application, and the size of the third parameter value is determined according to the user scenario of the electronic device.
The performance control method according to claim 1, characterized in that the method further comprises:

Sending the second parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the second parameter value;

The third parameter value is sent to the GPU driver, and the GPU driver controls the performance of the GPU according to the third parameter value.
According to the performance control method of claim 5, the electronic device further comprises BIOS and ACPI,

Sending the second parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the second parameter value, includes:

Transmitting the second parameter value to the BIOS via a WMI interface;

The BIOS writes the second parameter value into the first performance parameter storage location specified by the ACPI, and reads the second parameter value through the GPU driver;

The GPU driver reads the second parameter value, and controls the performance of the GPU according to the second parameter value;

Sending the third parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the third parameter value, includes:

Transmitting the third parameter value to the BIOS via a WMI interface;

The BIOS writes the third parameter value into the first performance parameter storage location specified by the ACPI, and reads the third parameter value through the GPU driver;

The GPU driver reads the third parameter value and controls the performance of the GPU according to the second parameter value.
The performance control method according to claim 2, characterized in that the method further comprises:

Sending the fifth parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the fifth parameter value;

The sixth parameter value is sent to the GPU driver, and the GPU driver controls the performance of the GPU according to the sixth parameter value.
According to the performance control method of claim 7, the electronic device further comprises BIOS and ACPI,

Sending the fifth parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the fifth parameter value, includes:

Transmitting the fifth parameter value to the BIOS via a WMI interface;

The BIOS writes the fifth parameter value into the second performance parameter storage location specified by the ACPI, and reads the fifth parameter value through the GPU driver;

The GPU driver reads the fifth parameter value and controls the performance of the GPU according to the fifth parameter value;

Sending the sixth parameter value to a GPU driver, wherein the GPU driver controls the performance of the GPU according to the sixth parameter value, includes:

Transmitting the sixth parameter value to the BIOS via a WMI interface;

The BIOS writes the sixth parameter value into the second performance parameter storage location specified by the ACPI, and Reading the sixth parameter value through the GPU driver;

The GPU driver reads the sixth parameter value and controls the performance of the GPU according to the sixth parameter value.
An electronic device, characterized in that it includes: a memory and a processor, wherein the memory and the processor are coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the performance control method as described in any one of claims 1 to 8.
A computer-readable storage medium, characterized in that it includes a computer program, characterized in that when the computer program is run on an electronic device, the electronic device executes the performance control method as described in any one of claims 1 to 8.