CN116028211B - Display card scheduling method, electronic equipment and computer readable storage medium - Google Patents

Abstract

The present application relates to the field of computer technology, and provides a graphics card scheduling method, an electronic device, and a computer-readable storage medium, the method comprising: obtaining the identifier of the APP to be started; obtaining the current power supply mode of the electronic device; based on a preset mapping relationship, determining the target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode, the target graphics card type is the type of graphics card called by the APP to be started during operation, the mapping relationship includes a plurality of power supply modes, a plurality of APP identifiers, and a plurality of graphics card types. The plurality of power supply modes include the current power supply mode, the identifiers of the plurality of APPs include the identifier of the APP to be started, and the plurality of graphics card types include the target graphics card type. The above method can improve the rationality of graphics card scheduling.

Description

Graphics card scheduling method, electronic device and computer readable storage medium

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on May 16, 2022, with application number 202210529195.3 and application name “Graphics card scheduling method, electronic device and computer-readable storage medium”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of computer technology, and in particular to a graphics card scheduling method, an electronic device, and a computer-readable storage medium.

Background technique

As the functions of electronic devices become more and more abundant, the scenarios in which people use electronic devices are also becoming more and more diverse, and the requirements for processing graphics images are also becoming higher and higher. In some electronic devices, a graphics card solution of independent graphics card plus integrated graphics card is often used.

Usually, when a graphics application (APP) is running, the electronic device needs to call the GPU resources to perform image processing to achieve the corresponding display effect. For APPs with large image processing operations, since the IGPU processing capacity is limited and cannot meet the normal graphics processing requirements, the electronic device will call the DGPU to perform image processing operations. For APPs with small image processing operations, the electronic device can call the IGPU to perform image processing.

However, the traditional method of determining whether to use the IGPU or the DGPU based on the amount of graphics processing computation of the APP is based on a single basis, which makes graphics card scheduling unreasonable.

Summary of the invention

The present application provides a graphics card scheduling method, device, chip, electronic device, computer-readable storage medium and computer program product, which can improve the rationality of graphics card scheduling.

In a first aspect, a graphics card scheduling method is provided, comprising: obtaining an identifier of an application program APP to be started; obtaining a current power supply mode of an electronic device; and determining, based on a preset mapping relationship, a target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode, wherein the target graphics card type is the type of graphics card called by the APP to be started during operation, and the mapping relationship includes a correspondence between multiple power supply modes, identifiers of multiple APPs, and multiple graphics card types, wherein the multiple power supply modes include the current power supply mode, the identifiers of multiple APPs include the identifier of the APP to be started, and the multiple graphics card types include the target graphics card type.

The electronic device determines whether the current APP to be started should call the integrated graphics card or the independent graphics card according to the type of APP to be started and the power supply method of the electronic device, thereby optimizing the power consumption in some scenarios where battery life is prioritized, and ensuring the performance in some scenarios where high performance is prioritized, making the scheduling of the graphics card more reasonable.

In some possible implementations, the multiple power supply modes include battery power supply and power supply, the multiple graphics card types include integrated graphics card and independent graphics card, the multiple APP identifiers include identifiers of high-performance category APPs and identifiers of low-performance category APPs, and the mapping relationships include: the correspondence between the identifier of the low-performance category APP, battery power supply, and integrated graphics card; the identifier of the low-performance category APP, power supply power, and independent graphics card; the identifier of the high-performance category APP, battery power supply, and independent graphics card; the identifier of the high-performance category APP, power supply power, and independent graphics card.

The above mapping relationship enables, when the APP is an APP with low requirements for graphics processing, that is, an APP of the category of low performance requirements, the electronic device can determine the graphics card to be used in combination with the power supply mode, so that when powered by the power supply, the independent graphics card is called to prioritize performance and optimize the display effect; when powered by the battery, the integrated graphics card is called to save power consumption, thereby balancing the user experience in different usage scenarios. When the APP is an APP with high requirements for graphics processing, that is, an APP of the category of high performance requirements, the electronic device will call the independent graphics card to prioritize the processing effect, whether it is powered by the battery or the power supply, to ensure the normal operation of the APP with high performance requirements, so as to ensure the user experience.

In some possible implementations, before obtaining the current power supply mode of the electronic device, it also includes: determining whether the APP to be started is an APP in a preset list based on the identifier of the APP to be started, and the APP in the preset list is an APP carrying a high-performance category identifier or an APP carrying a low-performance category identifier; if so, continue to execute the above-mentioned graphics card scheduling process.

The above preset list is a whitelist, and the APPs in the whitelist are APPs that have predetermined what type of graphics card to call in what scenario, that is, when running in the scenarios of power supply and battery power supply, they are APPs that need to call independent graphics cards or integrated graphics cards. Optionally, the whitelist can include multiple APPs, and can also include the graphics card type corresponding to each of these multiple APPs. Optionally, the graphics card type can also be distinguished by corresponding identifiers, for example, independent graphics cards are represented by DGPU, and integrated graphics cards are represented by IGPU.

In some possible implementations, the method further includes: if the APP to be started is not an APP in a preset list, obtaining a target graphics card type from a preset configuration file.

If the APP to be started is not in the whitelist, the default graphics card type of the APP to be started can be read from the default preset configuration file as the target graphics card type. Using the default graphics card preset configuration file to call the corresponding graphics card can ensure the orderly calling of the graphics card, that is, the original default fallback design is adopted, so there will be no problem of graphics card calling confusion in scenarios not covered by the above mapping relationship.

In some possible implementations, before determining whether the APP to be launched is an APP in a preset list based on the identifier of the APP to be launched, the method further includes: determining whether the APP to be launched is a graphic APP based on the identifier of the APP to be launched; if so, executing the step of determining whether the APP to be launched is an APP in the preset list based on the identifier of the APP to be launched.

If the APP to be started is a graphics APP, it can be determined that the graphics card scheduling issue is involved at this time, so the above graphics card scheduling process can be continued. If the APP to be started is not a graphics APP, it is determined that the graphics card scheduling issue is not involved, and the above graphics card scheduling process can be stopped, and the default graphics card configuration file can be used for processing.

In some possible implementations, when the current power supply mode is power supply by electrical source and the target graphics card type is an integrated graphics card, the method further includes: receiving a switching operation input by a user; and in response to the switching operation, switching the target graphics card type from an integrated graphics card to an independent graphics card.

The above power supply methods can also be described as power supply scenarios. For example, the power supply scenario of the power supply can be called a performance scenario, and the battery power supply scenario can be called a battery life scenario. Users can switch power supply scenarios by clicking the "Performance Scenario/Battery Life Scenario" button. If it is in the battery life scenario, if the battery power exceeds the preset power threshold, for example, more than 50%, and the user thinks that the power is sufficient at this time, then the user can manually switch the power supply scenario from the battery life scenario to the performance scenario. At this time, the DGPU can be called for graphics processing, giving priority to ensuring the display effect and improving the user experience. This method can also flexibly switch power supply scenarios to meet the various needs of users.

In some possible implementations, obtaining the identifier of the APP to be started includes: monitoring a newly created process through a process probe; and obtaining, according to the newly created process, the identifier of the APP to be started that is used to start the newly created process.

In some possible implementations, the method further includes: updating a preset configuration file according to the target graphics card type, the preset configuration file being used by the execution body to start the APP to be started according to the target graphics card type in the preset configuration file.

In some possible implementations, obtaining the current power supply mode of the electronic device includes: obtaining the current power supply mode through a scene recognition engine.

In some possible implementations, based on a preset mapping relationship, determining the target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode, including: determining the target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode based on the mapping relationship through a scheduling engine.

In a second aspect, a graphics card scheduling device is provided, comprising a unit composed of software and/or hardware, and the unit is used to execute any one of the methods in the technical solution described in the first aspect.

In a third aspect, an electronic device is provided, comprising: a processor, a memory and an interface; the processor, the memory and the interface cooperate with each other so that the electronic device executes any one of the methods in the technical solution described in the first aspect.

In a fourth aspect, an embodiment of the present application provides a chip, comprising a processor; the processor is used to read and execute a computer program stored in a memory to execute any one of the methods in the technical solution described in the first aspect.

Optionally, the chip also includes a memory, and the memory is connected to the processor via a circuit or wire.

Further optionally, the chip also includes a communication interface.

In a fifth aspect, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the processor executes any one of the methods in the technical solution described in the first aspect.

In a sixth aspect, a computer program product is provided, the computer program product comprising: a computer program code, when the computer program code is run on an electronic device, the electronic device executes any one of the methods in the technical solution described in the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

FIG2 is a schematic diagram of a software module architecture provided in an embodiment of the present application;

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

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

FIG5 is an interface diagram provided by an embodiment of the present application;

FIG6 is another schematic diagram of signal interaction 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 schematic diagram of a software module architecture provided in an embodiment of the present application;

FIG9 is a flow chart of a graphics card scheduling method provided in an embodiment of the present application;

FIG. 10 is a flowchart of another graphics card scheduling method provided in an embodiment of the present application.

FIG11 is a schematic diagram of a hardware module architecture provided in an embodiment of the present application;

FIG12 is a flow chart of a graphics card scheduling method provided in an embodiment of the present application;

FIG. 13 is a schematic diagram of the structure of a graphics card scheduling device provided in an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, "/" means or, for example, A/B can mean A or B; "and/or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

In the following, the terms "first", "second", and "third" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", and "third" may explicitly or implicitly include one or more of the features.

The graphics card scheduling method provided in the embodiment of the present application can be applied to electronic devices such as tablet computers, vehicle-mounted devices, augmented reality (AR)/virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. The embodiment of the present application does not impose any restrictions on the specific types of electronic devices.

Please refer to FIG. 1 , which is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application.

As shown in FIG. 1 , the electronic device 100 may include: a processor 110 , an external memory interface 120 , an internal memory 121 , a universal serial bus (USB) interface 130 , a charging management module 140 , a power management module 141 , a battery 142 , a wireless communication module 150 , a display screen 160 , etc.

It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

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

The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. While the charging management module 140 is charging the battery 142, it can also power the electronic device through the power management module 141.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory, the display screen 160, and the wireless communication module 150. In some embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

The wireless communication module 150 can provide wireless communication solutions including WLAN (such as Wi-Fi), Bluetooth, global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. For example, in the embodiment of the present application, the electronic device 100 can establish a Bluetooth connection with a terminal device (such as a wireless headset) through the wireless communication module 150.

The wireless communication module 150 may be one or more devices integrating at least one communication processing module. The wireless communication module 150 receives electromagnetic waves via an antenna, modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 150 may also receive a signal to be sent from the processor 110, modulate the frequency of the signal, amplify the signal, and convert it into electromagnetic waves for radiation via the antenna.

The electronic device 100 implements the display function through a GPU, a display screen 160, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 160 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

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

The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

The internal memory 121 may be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 may execute the instructions stored in the internal memory 121, and the internal memory 121 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 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

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. In the embodiment of the present invention, a Windows system with a layered architecture is used as an example to illustrate the software structure of the electronic device 100.

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

The layered architecture divides the software into several layers, each with clear roles 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. Among them, 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 2, the application layer includes applications such as music, video, games, office, and social networking. The application layer also includes an environment subsystem, a scene recognition engine, and a scheduling engine. 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 the basic scheduling strategy (also referred to as the 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 (also referred to as the first scheduling strategy) that conforms to the actual operation of the electronic device 100 in combination with the load condition of the electronic device 100 and the above-mentioned basic scheduling strategy. The specific contents of the scene recognition engine and the scheduling engine are described later and will not be described here for the time being.

The subsystem dynamic link library includes an API module, which includes Windows API, Windows native API, etc. Among them, Windows API and Windows native API can both 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, ntdll.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 can be used by the scheduling engine to send adjustment information to the hardware device, such as sending information to the CPU to adjust the sustained power limit (SPL) (or PL1) and slow package power tracking (s-PPT) (or PL2).

The kernel and driver layer includes 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 power-on, and the system self-starting program. It can read and write specific information of system settings from 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, the Hongmeng 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.

FIG. 3 is a schematic diagram showing the software and hardware workflow of the electronic device 100 for scheduling resources.

As shown in FIG3 , 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 to obtain 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 to subscribe 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 has changed, 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 usage scene may include video scenes, game scenes, office scenes, and social scenes. 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 FIG3 , the scheduling engine includes a load controller, a chip policy fusion device, and a scheduling executor. Among them, the load controller can receive the basic scheduling policy 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 policy according to the system load and the user scenario to obtain the actual scheduling policy (also referred to as the first scheduling policy, see the description in S310 below for details). The actual scheduling policy includes the OS scheduling policy and the first CPU power consumption scheduling policy (also referred to as the first sub-policy). Among them, the load controller can send the OS scheduling policy to the scheduling executor, and the scheduling executor performs scheduling based on the OS scheduling policy. The OS scheduling policy is used to adjust the process priority and I/O priority of the focus process. Exemplarily, the scheduling executor can 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 can 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 energy performance preference (EPP) to the power manager to adjust the EPP of the CPU. In addition, the scheduling executor can also send an instruction to adjust the SPL and s-PPT to the OS2SOC driver node to adjust the PL1 (which can be called SPL in the AMD platform) and PL2 (which can be called s-PPT in the AMD platform) 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 resource scheduling (including graphics card resource scheduling) 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; (2) performing resource scheduling according to the user scenario of the electronic device and the system load 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 4 to illustrate the interaction process of some modules in the electronic device shown in Figure 3. As shown in Figure 4, a resource scheduling method provided by an embodiment of the present application determines the user scenario in which the electronic device is located as follows:

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

As shown in Figure 3, 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.

S102. 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 S101, 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.

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

Still as shown in Figure 3, 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.

S104. 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.

S105. 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's needs are to browse and play videos. For another example, if the focus window is the window of a game application, it indicates that the user's needs are 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 needs have changed from watching videos to playing games.

It should be noted that there is no strict order between the above S101, S103 and S105. They can be executed in sequence according to the order shown in FIG4, or they can be executed simultaneously, or they can be executed in the order of S103, S101, S105, S103, S105, S101, S105, S101, S103, or S105, S103, S101. Correspondingly, there is no strict order between S102, S104 and S106. As long as S102 is executed after S101, S104 is executed after S103, and S106 is executed after S105, no specific restrictions are made here.

S106: In response to receiving an operation of starting the video application from the user, 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).

S107: 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.

Among them, the Windows operating system defines one 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) resource. A window is created by a thread, and a thread can own all windows it creates. In an embodiment of the present application, an 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 (i.e., 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.

S108. 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.

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

The description of the process creation event is shown in S108 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.

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

S111 . 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. 5 , the electronic device can display window 101, which can be a desktop, or can also be called a main interface. The window 101 includes an icon 102 of the video application. The electronic device can receive an operation of a user clicking on the icon 102 of the video application, and in response to the operation, as shown in (b) of FIG. 5 , the electronic device displays window 103 (i.e., window 1, or can also be called a first window). In the above process, the focus window changes from the original window 101 to window 103.

S112. 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 S106 to S111. 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.

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

S114: 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

application Process Name type video hlive.exe Video Word word.exe Office shooting game shot.exe Games WeChat wechat.exe Social … … …

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.

S115 , 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.

S116. 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.

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

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

S119, GPU performs decoding.

Specifically, the GPU may perform a decoding operation on the video file through a GPU video processing engine.

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

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

S122. 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.

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

S124. 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.

S125. 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.

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

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

S127: 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.

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

S129: 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.

S130. 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.

S131. The system probe module sends a request to the process manager to obtain a GPU engine of a 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 to perform encoding operations. The GPU video processing engine mainly performs decoding operations. In some embodiments, the GPU video processing engine can also be replaced by a GPU video decode engine.

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

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

S133. 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.

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

S135. 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 S129; if the GPU engine of the first process is not a GPU video processing engine, execute S130.

In step S114, 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 S135, 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 indicates that the first process is using the GPU for decoding operations, and it can be considered that the user is using a 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 indicates 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.

S136: 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, 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 S101 to S136 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 scenes, office scenes, social scenes, video browsing scenes, 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 CPU power mode is changed to 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, then it can be determined that the electronic device is in a game scene.

The power status probe of the system probe module can send a request to subscribe to the power mode change event to the power manager. The power manager can 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 can 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 S101, S102, S105, S106-S114 in Figure 4, 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 S124-S135. The difference is that the video application is replaced with a game application, which will not be repeated here.

Next, in conjunction with FIG6, a brief description is given of the process of determining the user scenario in which the electronic device is located when it is in an office scenario. It should be noted that the principle and process of the flowchart shown in FIG6 and the flowchart shown in FIG4 are basically detailed. 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 FIG4. FIG6 shows a resource scheduling 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:

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

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

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

As shown in Figure 3, 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.

S204. 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.

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

S206: 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.

S207: 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.

S208. The process manager reports the process creation event to the OsEventDriver node.

S209. 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.

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

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

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

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.

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

S214: 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.

S215: 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.

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

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

S219: 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. Alternatively, if the scene recognition engine determines that the type of the first process (focus process) belongs to the office category, and no mouse wheel sliding event, mouse click event, or keyboard input event is received again 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 scene in an office scene.

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) is social, 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 in a social scene.

The above content explains how to identify the user scenario of an electronic device. After determining the user scenario of an electronic device, the electronic device can also schedule resources according to its own user scenario and system load, so that the CPU of the electronic device can operate according to the actual needs of the user, thereby avoiding CPU overperformance without affecting the user experience.

Next, we continue to take the electronic device in the video playback scenario as an example to illustrate the resource scheduling process of the electronic device. As shown in FIG7 , a resource scheduling method provided in an embodiment of the present application has the following process for performing resource scheduling:

As shown in FIG. 7 , the resource scheduling method provided in the embodiment of the present application further includes:

S301. The scene recognition module sends scene information to the basic scheduling strategy matching manager.

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 S101 to S136 for details, which will not be repeated here.

S302: The basic strategy matching manager obtains scheduling strategy 1 according to the scenario information.

The scheduling policy 1 includes the OS scheduling policy 1 and the CPU power consumption scheduling policy 1. The OS scheduling policy 1 includes the first process priority and the first I/O priority of the first process. The scheduling policy 1 may also be referred to as the second scheduling policy.

The priority of the first process is used to measure the ability of the first process to seize the CPU. The higher its priority, the more preferentially it can meet its demand for CPU resources, thereby making the operation of the first process smoother. In an optional implementation, the priority of the focus process includes the following levels from high to low: real-time, high, above normal, normal, below normal, and low. Among them, the priority of the first process can also be understood as the focus process priority (FPP).

The I/O priority of the first process is used to measure the responsiveness of the system to the disk and I/O requests of the first process. The higher the priority, the higher the responsiveness of the disk and I/O requests of the first process, that is, the faster the response speed. In an optional embodiment, the focus process I/O priority includes the following levels from high to low: critical, high, normal, low, and very low. Among them, the I/O priority of the first process can also be understood as the focus process I/O priority (focus process IO priority, FPP_IO).

The CPU power consumption scheduling strategy 1 includes a first PL1 , a first PL2 , and a first EPP of the CPU.

It can be seen that scheduling strategy 1 can adjust the process priority, I/O priority, and CPU power consumption of the first process.

In an optional implementation, the electronic device may pre-configure various user scenarios and their corresponding scheduling strategies. Exemplarily, the correspondence between various user scenarios and their corresponding scheduling strategies may be as shown in Table 2.

Exemplarily, if it is determined that the user scenario in which the electronic device is located is a text chat scenario in a social scenario, then the scheduling strategy 1 includes: the first process priority of the first process is normal, the first I/O priority of the first process is normal, the first PL1 of the CPU is 12W, the first PL2 is 60W, and the first EPP is 220. It should be noted that the scheduling strategies in Table 2 are only examples. In actual applications, the values of process priority, I/O priority, PL1, PL2 and EPP may be inconsistent with the values in Table 2. In addition, Table 2 only shows the scheduling strategies for some scenarios, and actual electronic devices can be configured with more scheduling strategies than Table 2.

It should be noted that the above scheduling strategy is the default scheduling strategy for electronic devices in a light load state, which can pre-count the CPU power consumption of each application under the corresponding load characteristics for the electronic device, and configure the load characteristics and CPU power consumption according to the statistics. Therefore, the scheduling strategy 1 obtained by the basic strategy matching manager can be used as a reference solution for the strategy of scheduling electronic devices, and the electronic device can also obtain the actual scheduling strategy based on the scheduling strategy 1 and the actual system load.

Table 2

S303: The basic strategy matching manager sends the scheduling strategy 1 to the scene recognition module.

S304. The scene recognition module sends scheduling strategy 1 and scene information to the load controller.

That is, after the basic strategy matching manager determines the scheduling strategy 1, it forwards the scheduling strategy 1 to the load controller through the scene recognition module. In an optional implementation, the scene recognition module can send the scheduling strategy 1 and the scene information to the load controller in two steps.

S305. The load controller sends a request to the system probe module to obtain the system load.

The system load is the average number of processes in the runnable state and the processes in the uninterruptible state. The processes in the runnable state are the processes that are using the CPU or waiting to use the CPU. The processes in the uninterruptible state are the processes that are waiting for I/O access (for example, disk I/O).

S306: The system probe module sends a request to the process manager to obtain the system load.

As shown in Figure 3, the system probe module includes a system load probe, which can send a request to obtain the system load to the process manager. In an optional implementation, the OsEventDriver node can also forward the system load probe's request to obtain the system load to the process manager (not shown).

S307: The process manager obtains the system load.

S308. The process manager sends the system load to the system probe module.

Specifically, the process manager may send the system load to the system load probe of the system probe module. In an optional implementation, the OsEventDriver node may also forward the system load to the system load probe (not shown).

S309. The system probe module sends the system load to the load controller.

S310. The load controller obtains scheduling strategy 2 according to the system load, scenario information and scheduling strategy 1.

Scheduling strategy 2 may include OS scheduling strategy 2 (also referred to as OS scheduling strategy) and CPU power consumption scheduling strategy 2 (also referred to as first sub-strategy). CPU power consumption scheduling strategy 2 includes PL1`, PL2`, and EPP`, where PL1` is PL1 adjusted by the load controller, and may also be referred to as the second PL1. PL2` is PL2 adjusted by the load controller, and may also be referred to as the second PL2. EPP` is EPP adjusted by the load controller, and may also be referred to as the second EPP. Among them, scheduling strategy 2 may also be referred to as the first scheduling strategy.

In an optional implementation, the load controller can divide the system load into three levels, namely light load, medium load, and heavy load. The electronic device can pre-configure various user scenarios and their corresponding adjustment strategies. For example, the adjustment strategy can be shown in Table 3:

table 3

For example, if the electronic device is in a video playback scene, and according to Table 2, the scheduling strategy 1 is: the process priority of the video application process is normal, the I/O priority of the video application process is normal, the PL1 (i.e., the first PL1) of the CPU is 18W, the PL2 (i.e., the first PL2) is 60W, and the EPP (i.e., the first EPP) is 200. In this case, if the system load is a light load, there is no need to adjust the scheduling strategy, that is, the scheduling strategy 2 is the scheduling strategy 1. If the system load is a medium load, it is necessary to keep the process priority of the video application process normal, the I/O priority of the video application process normal, PL1 increases by 22W on the basis of 18W, PL2 increases by 30W on the basis of 60W, and EPP decreases by 50 on the basis of 200, that is, the scheduling strategy 2 is: the process priority of the video application process is normal, the I/O priority of the video application process is normal (OS scheduling strategy 2), PL1` is 40W, PL2` is 90W, and EPP` is 150 (CPU scheduling strategy 2). If the system load is heavy, the process priority of the video application process needs to be kept normal, and the I/O priority of the video application process is adjusted to high. PL1 is increased by 37W on the basis of 18W, PL2 is increased by 45W on the basis of 60W, and EPP is reduced by 100 on the basis of 200. That is, scheduling strategy 2 is: the process priority of the video application process is normal, the I/O priority of the video application process is high, PL1` is 55W, PL2` is 105W, and EPP` is 100.

It should be noted that Table 3 only shows some user scenarios and their corresponding adjustment strategies. The electronic device can also be configured with more adjustment strategies than those in Table 3, and no specific limitation is made here.

In an optional implementation, the system load and the CPU power consumption satisfy a specific mapping relationship (for example, mapping through a specific formula), and the load controller can also calculate the CPU power consumption through the specific formula and the system load, and then obtain scheduling strategy 2.

S311. The load controller sends OS scheduling strategy 2 to the scheduling executor.

The OS scheduling policy 2 includes a second process priority and a second I/O priority of the first process.

S312, the scheduling executor sends instruction 1 to the I/O manager.

Instruction 1 carries the second I/O priority of the first process. In addition, as shown in Figure 3, the scheduling executor includes an I/O priority interface, which can send instruction 1 to the I/O manager. Instruction 1 can also be called a second instruction.

S313: In response to instruction 1, the I/O manager adjusts the I/O priority of the first process.

That is, the I/O manager can adjust the I/O priority of the first process to the second I/O priority, so as to ensure that the first process can perform I/O access preferentially and reduce the response time of the first process during the I/O access process.

S314. The scheduling executor sends instruction 2 to the process manager.

Instruction 2 carries the second process priority of the first process. In addition, as shown in Figure 3, the scheduling executor also includes a process priority interface, which can send instruction 2 to the process manager. Instruction 2 can also be called a first instruction.

S315. In response to receiving instruction 2, the process manager adjusts the process priority of the first process.

That is, the process manager can adjust the process priority of the first process to the second process priority. In this way, the first process can take up CPU resources first, ensuring that the first process can run smoothly.

It can be seen that by adjusting the I/O priority and process priority of the first process, the I/O access and CPU resource consumption of the first process can be prioritized, so that the first process can run normally and smoothly, ensuring that users have a good experience.

It should be noted that there is no strict order between S312 and S314. S312 may be executed first and then S314, or S314 may be executed first and then S312, or S314 and S312 may be executed simultaneously.

S316. The load controller sends CPU power consumption scheduling strategy 2 to the chip strategy aggregator.

S317, the chip strategy fusion device determines the CPU chip platform type is or/>

The company's CPU chips and/> The CPUs of different companies have different ways of adjusting CPU power consumption, so they need to be differentiated. Among them, if the CPU chip platform type is/> (also called the first type), then execute S318; if the CPU chip platform type is/> (also referred to as the second type), then execute S325.

S318, the chip policy aggregator sends the CPU power consumption scheduling policy 2 to the scheduling executor.

Among them, the CPU power consumption scheduling strategy 2 includes PL1`, PL2`, and EPP`.

S319, the scheduling executor sends instruction 3 to the OS2SOC driver node.

Instruction 3 carries PL1' and PL2'. That is, instruction 3 is used to adjust PL1 and PL2 of the CPU. Instruction 3 can also be called the third instruction.

In an optional implementation, the CPU power consumption scheduling interface of the scheduling executor may send instruction 3 to the OS2SOC driver node.

S320, the OS2SOC driver node sends instruction 3 to the CPU.

S321 . In response to instruction 3 , the CPU adjusts PL1 and PL2 .

That is, the CPU may adjust PL1 to PL1` and PL2 to PL2`.

S322. The scheduling executor sends instruction 4 to the power manager.

Among them, instruction 4 carries EPP`. That is, instruction 4 is used to adjust the EPP of the CPU. Instruction 4 can also be called the fourth instruction.

S323: The power manager sends instruction 4 to the CPU.

S324. In response to instruction 4, the CPU adjusts the EPP.

That is, the CPU may adjust EPP to EPP`.

S325 . The chip strategy aggregator determines the dynamic tuning technology strategy number according to CPU power consumption scheduling strategy 2 .

Dynamic tuning technology (DTT) is The company is in/> Processor and /> A technology that automatically and dynamically allocates power consumption between discrete graphics cards to optimize performance and extend battery life. It can improve the performance of the CPU and GPU and balance power for intelligent mixed workloads.

It can be understood that there can be a mapping relationship between the DTT policy number and the CPU power consumption scheduling policy 2. A DTT policy table will be constructed in the BIOS, and any CPU power consumption scheduling policy 2 can be mapped to a DTT policy number in the DTT policy table through the parameters (PL1`, PL2`, EPP`) therein, as shown in Table 4.

Among them, the DTT policy number can be used to identify a DTT policy (also called the second sub-policy), and the DTT policy corresponding to the DTT policy number is used to adjust the CPU's PL1_MINI, PL1_MAX, PL2, PL2_TIME, and EPO Gear. PL1_MINI is the minimum value of PL1, PL1_MAX is the maximum value of PL1, and PL2_TIME is the duration of PL2. Energy Performance Optimize Gear (EPO Gear) is used to characterize the intensity of DTT's adjustment of the CPU energy efficiency ratio (EPP). The value range is between 1 and 5. The larger the value, the more energy efficiency is favored when adjusting EPP; the smaller the value, the more performance is favored when adjusting EPP.

It should be noted that Table 4 only shows the correspondence between some PL1', PL2', EPP' and DTT policy numbers, and may actually include more information than Table 4. For example, if the CPU power consumption scheduling policy 2 indicates that PL1' is -1, PL2' is -1 and EPP' is -1, it can be determined that the DTT policy number is 0, and its corresponding PL1_MINI is 30, PL1_MAX is 40, PL2 is 95, PL2_TIME is 28, and EPO Gear is 3.

S326. The chip strategy aggregator sends the DTT strategy number to the scheduling executor.

In an optional implementation, the chip strategy aggregator may also directly send the functional DTT strategy (ie, the second sub-strategy) corresponding to the DTT strategy number to the scheduling executor.

Table 4

S327, the scheduling executor sends the DTT policy number to the Intel DTT driver.

S328, Intel DTT driver sends DTT policy number to CPU.

It can be understood that the Intel DTT driver can send the DTT policy number to the CPU through the BIOS.

S329, the CPU runs based on the DTT strategy number.

It can be seen that if the CPU chip platform type is The chip strategy fusion can send an instruction to adjust the EPP to the power manager through the scheduling executor, and the power manager can 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, and the OS2SOC driver node drives the PL1 and PL2 of the CPU.

If the CPU chip platform type is The chip policy aggregator can then determine the CPU power consumption scheduling strategy 2 to obtain the DTT policy number, and send the DTT policy number to the Intel DTT driver through the scheduling executor via the BIOS, so that the CPU runs based on the DTT policy number to achieve the effect of adjusting power consumption.

It can be understood that the present application can obtain the focus window change event and the first information (including the process information of the focus process, the occupancy of the GPU by the focus process, peripheral events and power mode, etc.), and determine the user scenario in which the electronic device is currently located based on the focus window change event and the first information, and determine the first scheduling strategy in combination with the user scenario and the system load of the electronic device, and adjust the process priority, I/O priority and CPU power consumption of the focus process based on the first scheduling strategy, so as to reduce the energy consumption of the electronic device while smoothly meeting user needs (ensuring smooth operation of the focus process).

The above is an introduction to the overall framework and overall functions involved in this case. The above software architecture can also be simplified to the structure shown in Figure 8. As shown in Figure 8, the software architecture can include an application layer, a kernel and driver layer, and a hardware layer from top to bottom.

Specifically, the application layer can install the PC Manager APP, which can manage and schedule PC resources. The PC Manager can identify a variety of scenarios based on different probes, such as music scenarios, video scenarios, game scenarios, office scenarios, and social scenarios. The PC Manager includes a scenario recognition engine and a scheduling engine.

The kernel and driver layer include the graphics card driver, which stores the graphics card configuration file. The graphics card configuration file is used to provide the type of graphics card used by the process at the process startup stage, whether to use an integrated graphics card (IGPU) or a discrete graphics card (DGPU). Integrated graphics cards have lower energy consumption, but weaker graphics processing capabilities than discrete graphics cards; discrete graphics cards have stronger graphics processing capabilities, but higher energy consumption than integrated graphics cards.

The hardware layer includes the central processing unit (CPU), integrated graphics processing unit (IGPU), discrete graphics processing unit (DGPU), memory and other hardware devices.

For ease of understanding, the following embodiments of the present application will take an electronic device having the structure shown above as an example, and combine the accompanying drawings and application scenarios to specifically explain the graphics card scheduling method provided in the embodiments of the present application.

Usually, during the operation of graphics apps, it is necessary to call on the resources of the GPU to perform image processing to achieve the corresponding display effect. For apps with a large amount of image processing calculations, they can be marked as apps with high performance requirements. Since the processing power of the IGPU is limited and cannot meet the normal graphics processing requirements, the DGPU will be called to perform image processing. For apps with a small amount of image processing calculations, the IGPU can be used to perform image processing, which can not only meet usage needs but also save energy. Therefore, the electronic device only needs to determine whether the APP is marked with high-performance requirements. If so, the DGPU is called, and if not, the IGPU is called.

However, the method of determining whether to use IGPU or DGPU based on whether the APP has high performance requirements is single-based and cannot reasonably balance performance and power consumption, which may lead to waste of power consumption in some cases.

In the strategy of this application, the electronic device can use a variety of probes to obtain the scene in which the current electronic device is located, and then determine whether the current APP calls the IGPU or DGPU based on the scene in which it is located and the power supply mode of the power supply, so as to optimize the power consumption in some scenarios where battery life is prioritized, and ensure the performance in some scenarios where high performance is prioritized. The scenarios mentioned here may include one or more combinations of the type of APP running on the electronic device, whether the external device (mouse, keyboard, power supply, headphones, camera, etc.) is connected, whether the electronic device is connected to an external power supply (i.e., whether it is powered by the power supply (AC mode)), whether the power is sufficient, and so on.

In some embodiments, a flowchart of a graphics card scheduling method may be shown as 9, including:

S901. Obtain the identifier of the APP to be started.

Specifically, the probe for detecting the process detects that there is a newly created process 1, for example, a user clicks on an APP icon to open the APP, then the electronic device responds to the user's click operation, creates a new process to prepare to run the APP, called the APP to be started, and obtains the identifier of the APP to be started. In some embodiments, the probe for detecting the process sends the identifier of the APP to be started to the scene recognition engine, and the scene recognition engine can obtain the identifier of the APP to be started corresponding to the newly created process.

S902: Obtain the current power supply mode of the electronic device.

The electronic device can also obtain the current power supply mode in the current state according to the power supply mode of the electronic device reported by each probe. For example, the probe for power supply detection can be used to obtain whether the power socket is in place, and if so, it is determined that the current power supply mode is power supply, and if not, it is determined that the current power supply mode is battery power supply.

S903. Based on a preset mapping relationship, determine the target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode. The target graphics card type is the type of graphics card called by the APP to be started during its operation. The mapping relationship includes a correspondence between multiple power supply modes, identifiers of multiple APPs, and multiple graphics card types. The multiple power supply modes include the current power supply mode, the identifiers of multiple APPs include the identifier of the APP to be started, and the multiple graphics card types include the target graphics card type.

The above mapping relationship can be the correspondence between the APP identifier - power supply method (also known as power supply mode) - graphics card type. The electronic device obtains the corresponding graphics card type by searching for the identifier and power supply method of the APP to be started in the mapping relationship, and uses the graphics card type as the target graphics card type so that it can be called when running the APP to be started.

The identifier of the APP to be started may also be the application scenario of the electronic device running the APP to be started, and the mapping relationship may be the corresponding relationship of application scenario-power mode-graphics card type. The electronic device obtains the corresponding graphics card type by searching the scenario identifier and power mode of the application scenario, and uses the graphics card type as the target graphics card type so as to call it when running the APP to be started.

In the embodiment shown in FIG. 9 above, the current power supply mode is combined to determine which graphics card the APP will call in subsequent operation, so as to balance the display performance and battery life according to the power supply mode. For example, for an APP with high requirements for graphics processing, the IGPU cannot run normally, so the DGPU is directly called to prioritize performance; for an APP with low requirements for graphics processing, the IGPU can be called in the battery-powered mode to meet the graphics processing requirements while reducing power consumption, and in the power supply mode, the battery life requirements can be ignored and the DGPU can be called. This method improves the rationality of graphics card scheduling and enhances user experience.

In some embodiments, a flowchart of a graphics card scheduling method may be shown as 10, including:

S1001. Obtain the identifier of the APP to be started corresponding to the newly created process.

Specifically, the probe for detecting processes detects a newly created process 1, that is, a new APP is about to be opened on the electronic device, which is called the APP to be started, recorded as APP1. At this time, the electronic device can obtain the APP1 to be started corresponding to the newly created process. In some embodiments, the probe for detecting processes detects the newly created process 1, and can also determine that the APP to be started at this time is APP1 based on the name of the newly created process 1 and the signature information of the newly created process 1, and obtain the identifier of APP1. Optionally, before starting the APP1, the electronic device can also verify whether the signature certificate is available based on the signature information of the newly created process 1. If available, continue to execute subsequent steps. After that, the electronic device sends the identifier of APP1 to the scene recognition engine, and the scene recognition engine can obtain the identifier of the APP to be started corresponding to the newly created process.

S1002: Determine whether the APP to be started is an APP in a preset whitelist according to the identifier of the APP to be started. If yes, execute step S1003A; if no, execute step S1003B.

It should be noted that the APPs in the whitelist are APPs that have predetermined the types of graphics cards to be called in what scenarios, that is, they are APPs that need to call independent graphics cards or integrated graphics cards when they are powered by power supply and battery power respectively during operation. Optionally, the whitelist may include multiple APPs, and may also include the graphics card type corresponding to each of these multiple APPs. Optionally, the graphics card type can also be distinguished by corresponding identifiers, for example, independent graphics cards are represented by DGPU, and integrated graphics cards are represented by IGPU. Optionally, the whitelist can be stored in the configuration file of PC Manager.

The electronic device can search for the identifier of the APP to be started in the preset white list. For example, the electronic device searches for the identifier of APP1 in the white list. If it can be found, it is determined that the APP to be started is an APP in the white list; if it is not found, it is determined that the APP to be started is not in the white list.

In some embodiments, the electronic device can use the scene recognition engine to search the whitelist according to the identifier of APP1. If APP1 is found, it can be determined that APP1 is an APP in the whitelist; if APP1 is not found, it can be determined that APP1 is not an APP in the whitelist.

The above whitelist may also include, for example, apps with high display requirements, such as gaming apps, or apps with low display requirements, such as music apps.

S1003A: If the APP to be started is an APP in the whitelist, obtain the current power supply mode of the electronic device.

The electronic device can also obtain whether it is currently powered by a mains supply or a battery according to the power supply mode of the electronic device reported by each probe.

In some embodiments, probes of various scenes can obtain various current states of electronic devices and report these states to the scene recognition engine. The electronic device identifies the current scene identifier based on these states through the scene recognition engine, and the scene identifier can carry the power supply mode. Optionally, the above scene identifier can also be other types of identifiers such as scene names and scene codes, which are not limited in the embodiments of the present application.

Optionally, the scene identifier may be a scene number, which includes multiple fields, and different fields represent states detected by different probes. For example, the scene number may include a field representing the power supply mode. For example, if the power supply mode field is 0, it may indicate that the current electronic device is in AC mode, that is, a power supply is plugged in and it is a power supply mode; if the power supply mode field is 1, it may indicate that the current electronic device is in battery power supply (i.e., DC mode), that is, no power supply is plugged in and it is a battery-powered mode.

S1003B: If the APP to be started is not in the whitelist, determine that the graphics card corresponding to the APP to be started in the configuration file of the default graphics card is the target graphics card.

At this time, there is no need to modify the graphics card configuration file. Using the default graphics card configuration file to call the corresponding graphics card can ensure the orderly calling of the graphics card, that is, using the original default fallback design, so there will be no problem of graphics card calling confusion in scenarios not covered by the above correspondence.

S1004: Determine a target graphics card to be called when the APP to be started is running according to the identifier of the APP to be started and the power supply method.

The electronic device can also search in a preset mapping relationship according to the identification and power supply mode of the APP to be started, and obtain the target graphics card corresponding to the identification and power supply mode of the APP to be started. The corresponding relationship may include the identification of the APP in the whitelist, the power supply mode (AC and DC), and the corresponding relationship of the graphics card type.

Optionally, the above mapping relationship may also be a correspondence between multiple scene identifiers and different graphics cards. The scene identifier includes information characterizing the power supply mode of the power supply. The multiple scene identifiers in the correspondence are different from each other, but the graphics card corresponding to each scene identifier may correspond to the same graphics card as some other scene identifiers. When the graphics card type includes IGPU and DGPU, different scene identifiers correspond to IGPU or DGPU respectively.

Optionally, the electronic device may also obtain a scene identifier in the current scene, and search in the corresponding relationship in combination with the identifier of the APP to be started to obtain the target graphics card.

In some embodiments, the electronic device may also send the scene identifier to the scheduling engine through the scene recognition engine. For example, the scene number may be sent to the scheduling engine, or the field representing the power supply mode of the power supply in the scene number may be sent to the scheduling engine, which is not limited in this embodiment. The scheduling engine determines the type of graphics card that needs to be called when the APP to be started is running in the current scene according to the power supply mode carried by the scene identifier, so as to realize dynamic adjustment of the graphics card scheduling.

Optionally, some correspondences between scene identifiers and graphics card types can be preset, such as: scene number--graphics card type correspondence, and usually, the scene number can carry a field for the power supply mode. The scheduling engine can find the graphics card type corresponding to the scene number in the correspondence, and then write this graphics card type into the configuration file of the graphics card driver, so that APP1 calls the written graphics card type after startup.

Optionally, some mapping relationships between APPs and graphics card types can also be pre-set. For example, game APPs correspond to DGPU, and evaluation APPs correspond to DGPU. For another example, conference APPs correspond to IGPU, video APPs correspond to IGPU, music APPs correspond to IGPU, and social APPs correspond to IGPU. This correspondence method can ensure that when an APP with high graphics processing requirements is running, the DGPU with strong graphics processing capabilities is called to ensure processing performance; and when an APP with low graphics processing requirements is running, the IGPU with weak graphics processing capabilities is called to ensure that the display requirements are met while reducing power consumption.

Optionally, the corresponding relationship may also include a mapping relationship of the current power supply mode, that is, the corresponding relationship is: application scenario--power supply mode--graphics card type, the corresponding relationship among the three. For example, conference APP, DC mode, IGPU correspondence; conference APP, AC mode, DGPU correspondence; video APP, DC mode, IGPU correspondence; video APP, AC mode, DGPU correspondence; music APP, DC mode, IGPU correspondence; music APP, AC mode, DGPU correspondence; video APP, AC mode, DGPU correspondence; social APP, DC mode, IGPU correspondence; social APP, AC mode, DGPU correspondence; office APP, DC mode, IGPU correspondence; office APP, AC mode, DGPU correspondence; browser APP, DC mode, IGPU correspondence; browser APP, AC mode, DGPU correspondence. This correspondence allows the electronic device to determine the graphics card to be used based on the power supply method when the APP does not have high requirements for graphics processing, so that when powered by power supply, the DGPU is called to prioritize performance and optimize display effects; when powered by battery, the IGPU is called to save power consumption, thereby balancing the user experience in different usage scenarios.

The electronic device can determine the type of graphics card that needs to be called when the APP to be started is running according to the application scenario represented by the scenario number and the power supply mode of the power supply. In some embodiments, the following corresponding relationship can be referred to:

When the APP to be launched is a gaming APP, regardless of whether the power supply mode is AC or DC, the corresponding graphics card type is DGPU; when the application scenario is an evaluation scenario (such as a classification scenario), regardless of whether the power supply mode is AC or DC, the corresponding graphics card type is also DGPU to prioritize performance.

When the APP to be started is an office APP and the power supply mode is DC, the corresponding graphics card type is IGPU; when the APP to be started is a music APP and the power supply mode is DC, the corresponding graphics card type is IGPU; when the APP to be started is a video APP and the power supply mode is DC, the corresponding graphics card type is IGPU; when the APP to be started is a social APP and the power supply mode is DC, the corresponding graphics card type is IGPU; when the APP to be started is a conference APP and the power supply mode is DC, the corresponding graphics card type is IGPU, to prioritize the battery life of the electronic device.

When the APP to be started is an APP with low image processing computational complexity, such as office APP, music APP, video APP, social APP and conference APP, and the power supply mode of the electronic device is AC, the electronic device believes that there is no need to consider the power consumption issue in the power supply mode, and the original default graphics card type of each APP is adopted, that is, there is no need to modify the configuration file of the graphics card driver.

In other application scenarios, the default graphics card type can be called, that is, there is no need to modify the graphics card driver configuration file.

The above settings are for situations where the graphics processing requirements are high (i.e., high performance is prioritized). If IGPU is used, it cannot run normally, so DGPU is directly called to prioritize performance. In other situations where the graphics processing requirements are low and the system is in battery mode (i.e., battery life is prioritized), IGPU is called to meet the graphics processing requirements while reducing power consumption. The above specific scenarios are set, while the default graphics card type is used for other scenarios based on the principle of minimum modification. While optimizing the experience of specific scenarios, it simplifies the design, reduces the difficulty of design, reduces the labor cost of electronic equipment during the research and development process, and shortens the research and development cycle of electronic equipment.

In the embodiment shown in FIG. 10 above, since the APPs in the whitelist correspond to the types of graphics cards called under different power supply modes, when the electronic device starts the APP in the whitelist, it can determine which graphics card the APP will call in the subsequent operation in combination with the current power supply mode, so as to balance the display performance and battery life according to the power supply mode. For example, for APPs with high requirements for graphics processing, the IGPU cannot run normally, so the DGPU is directly called to give priority to performance; for APPs with low requirements for graphics processing, the IGPU can be called in the battery-powered mode to meet the graphics processing requirements while reducing power consumption, and in the power supply mode, the battery life requirements can be ignored and the DGPU can be called. This method improves the rationality of graphics card scheduling and enhances user experience.

In some embodiments, the above-mentioned power supply mode can also be described as a power supply scenario. For example, the power supply scenario can be called a performance scenario, and the battery power supply scenario can be called a battery life scenario, which is not limited in this application. Optionally, in addition to the results of the probe detection, the power supply scenario can also be set manually. For example, the user can switch the power supply scenario by clicking the "Performance Scenario/Battery Life Scenario" button on the PC housekeeper interface. For example, in a performance scenario (i.e., a power supply scenario), if the APP currently running on the electronic device is the case of calling the IGPU, the user can click the "Performance Scenario/Battery Life Scenario" button on the PC housekeeper interface to switch from the scene of calling the IGPU to the state of calling the DGPU for graphics processing, thereby improving the image processing capability, without having to pay attention to power consumption.

When the scheduling engine determines the target graphics card that needs to be scheduled for the APP to be started, the configuration files of the graphics card in the kernel and driver layer can be modified through the execution body. After that, the graphics card driver reads the modified configuration file, and according to the graphics card type indicated in the modified configuration file of the graphics card, starts the target graphics card to execute the startup process of the APP to be started, so that the APP to be started runs on the determined target graphics card. If the scheduling engine determines the graphics card type that needs to be scheduled for the APP to be started, and when the configuration file of the graphics card driver is modified through the execution body, it is found that the new graphics card type obtained is the same as the graphics card type in the original configuration file, the configuration file of the graphics card driver can be kept unchanged, so that the modification operation can be reduced while ensuring the reasonableness of the graphics card call, saving resources. For example, if the scheduling engine determines that the APP to be started needs to be scheduled as DGPU, the configuration file of the graphics card can be modified through the execution body. If the graphics card type configured for the APP to be started in the original graphics card configuration file is IGPU, it needs to be modified to DGPU at this time. If the graphics card type configured for the APP to be started in the original graphics card configuration file is DGPU, it does not need to be modified at this time.

In some embodiments, the structural diagram of the hardware layer can also be seen in Figure 11. Usually, a dedicated memory (Video Memory) is set up separately for the DGPU. When the DGPU is called for calculation, the DGPU can send the calculation result to the CPU through the high-speed serial computer expansion bus standard channel (PCIE, peripheral component interconnectexpress) bus, which is passed from the CPU to the IGPU, and finally passed to the display (Display) through the IGPU for display. If the IGPU is called for calculation, the IGPU can directly send the calculation result to the display. In some embodiments, the DGPU can also send the result directly to the display through the channel between the DGPU and the display instead of the IGPU.

In order to more clearly describe the technical solution of this case, the technical solution of the embodiment of the present application is described here with the specific process shown in FIG. 12, including:

S1201. A registered application (eg, PC Manager) starts monitoring.

S1202, the graphics APP (the APP to be started) is started.

S1203: receiving a startup notification of a graphics APP (ie, monitoring a newly created process).

S1204: Determine whether the graphic app is an app in the whitelist. If yes, execute S1205; if no, execute S1208.

S1205. Query whether the current scenario is a battery life scenario or a performance scenario.

S1206: Decide whether to use the IGPU or the DGPU based on the current scenario.

S1207. Modify the configuration file according to the decision result.

S1208: Read the configuration file.

S1209: Schedule the IGPU or DGPU according to the configuration file.

The implementation principles and beneficial effects of each step in the embodiment of Figure 12 can be found in the description of the previous embodiment, and will not be repeated here.

The above describes in detail an example of the graphics card scheduling method provided by the present application. It is understandable that, in order to implement the above functions, the corresponding device includes a hardware structure and/or software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

The present application can divide the graphics card scheduling device into functional modules according to the above method example. For example, each function can be divided into each functional module, or two or more functions can be integrated into one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

FIG13 is a schematic diagram of a structure of a graphics card scheduling device 1300 provided in an embodiment of the present application. The device includes:

The first acquisition module 1301 is used to acquire the identifier of the application program APP to be started.

The second acquisition module 1302 is used to acquire the current power supply mode of the electronic device.

Determination module 1303 is used to determine the target graphics card type corresponding to the identifier of the APP to be started and the current power supply mode based on a preset mapping relationship. The target graphics card type is the type of graphics card called by the APP to be started during its operation. The mapping relationship includes the correspondence between multiple power supply modes, multiple APP identifiers and multiple graphics card types. The multiple power supply modes include the current power supply mode, the multiple APP identifiers include the identifier of the APP to be started, and the multiple graphics card types include the target graphics card type.

In some embodiments, the multiple power supply modes include battery power supply and power supply, the multiple graphics card types include integrated graphics card and independent graphics card, the multiple APP identifiers include identifiers of high-performance category APPs and identifiers of low-performance category APPs, and the mapping relationships include: the identifier of low-performance category APP, battery power supply and corresponding integrated graphics card; the identifier of low-performance category APP, power supply power and corresponding independent graphics card; the identifier of high-performance category APP, battery power supply and corresponding independent graphics card; the identifier of high-performance category APP, power supply power and corresponding independent graphics card.

In some embodiments, the second acquisition module 1302 is also used to determine whether the APP to be started is an APP in a preset list based on the identifier of the APP to be started before acquiring the current power supply mode of the electronic device, and the APP in the preset list is an APP carrying a high-performance category identifier or an APP carrying a low-performance category identifier; if so, execute the step of obtaining the current power supply mode of the electronic device.

In some embodiments, the determination module 1303 is further configured to obtain a target graphics card type from a preset configuration file when the APP to be started is not an APP in a preset list.

In some embodiments, the second acquisition module 1302 is further used to determine whether the APP to be started is a graphic APP according to the identification of the APP to be started; if so, executing the step of determining whether the APP to be started is an APP in a preset list according to the identification of the APP to be started.

In some embodiments, when the current power supply mode is power supply and the target graphics card type is an integrated graphics card, the determination module 1303 is also used to receive a switching operation input by the user, and in response to the switching operation, the target graphics card type is switched from an integrated graphics card to an independent graphics card.

In some embodiments, the first acquisition module 1301 is specifically configured to monitor a newly created process through a process probe; and, based on the newly created process, acquire an identifier of an APP to be started that is used by the newly created process to start.

In some embodiments, the second acquisition module 1302 is specifically configured to acquire the current power supply mode through a scene recognition engine.

In some embodiments, the determination module 1303 is specifically configured to determine, through a scheduling engine based on a mapping relationship, the identifier of the APP to be started and the target graphics card type corresponding to the current power supply mode.

In some embodiments, the determination module 1303 is further used to update a preset configuration file according to the target graphics card type, and the preset configuration file is used for the execution body to start the to-be-started APP according to the target graphics card type in the preset configuration file.

The specific manner in which the graphics card scheduling device executes the graphics card scheduling method and the beneficial effects produced can be found in the relevant description in the method embodiment, which will not be repeated here.

An embodiment of the present application also provides an electronic device, including the above-mentioned processor. The electronic device provided in this embodiment can be a terminal device as shown in Figure 1, such as a laptop computer, used to execute the above-mentioned graphics card scheduling method. In the case of an integrated unit, the terminal device may include a processing module, a storage module and a communication module. Among them, the processing module can be used to control and manage the actions of the terminal device, for example, it can be used to support the terminal device to execute the steps performed by the display unit, the detection unit and the processing unit. The storage module can be used to support the terminal device to execute stored program codes and data, etc. The communication module can be used to support the communication between the terminal device and other devices.

Among them, the processing module can be a processor or a controller. It can implement or execute various exemplary logic boxes, modules and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a device that interacts with other terminal devices, such as a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, etc.

In one embodiment, when the processing module is a processor and the storage module is a memory, the terminal device involved in this embodiment may be a device having the structure shown in FIG. 1 .

An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes the graphics card scheduling method described in any of the above embodiments.

The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the graphics card scheduling method in the above-mentioned embodiment.

Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above and will not be repeated here.

In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, the replaced units may or may not be physically separated, and the components displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (6)

1. The display card scheduling method is applied to the electronic equipment and is characterized by comprising the following steps of:

The probe of the detection process detects that a new process exists, and whether the signature certificate is available or not is checked according to the signature information of the new process;

If the application program APP is available, the identification of the application program APP corresponding to the new process is sent to a scene recognition engine, and the APP corresponding to the new process is the APP to be started;

The scene recognition engine receives the identification of the APP to be started, which is detected by the probe of the detection process;

Determining whether the APP to be started is an APP in a preset list according to the identification of the APP to be started, wherein the APP in the preset list is the APP carrying the high-performance type identification or the APP carrying the low-performance type identification;

If yes, the probe for the power supply in-place detection reports the current power supply mode in the current state to the scene recognition engine;

Searching an identification of the APP to be started and the current power supply mode in a preset mapping relation, wherein the mapping relation comprises a plurality of power supply modes, a plurality of identifications of the APP and a plurality of corresponding relations of display card types, the plurality of power supply modes comprise the current power supply mode, the plurality of identifications of the APP comprise the identification of the APP to be started, the plurality of display card types comprise target display card types, and the target display card types are types of display cards called by the APP to be started in the operation process;

When the identification of the APP to be started is the identification of the APP with low performance class and the current power supply mode is battery power supply, determining the integrated display card as a target display card type;

When the identification of the APP to be started is the identification of the APP with low performance class and the current power supply mode is power supply, determining the independent display card as a target display card type;

When the identification of the APP to be started is the identification of the APP with high performance class and the current power supply mode is battery power supply, determining the independent display card as a target display card type;

when the identification of the APP to be started is the identification of the APP with high performance class and the current power supply mode is power supply, determining the independent display card as a target display card type;

If the APP to be started is not the APP in the preset list, acquiring the target video card type from a preset configuration file;

the integrated display card and the independent display card are arranged inside the electronic equipment.

2. The method of claim 1, wherein before determining whether the APP to be started is an APP in a preset list according to the identification of the APP to be started, further comprises:

determining whether the APP to be started is a graph type APP or not according to the identification of the APP to be started;

if yes, executing the step of determining whether the APP to be started is the APP in the preset list according to the identification of the APP to be started.

3. The method according to claim 1 or 2, wherein when the current power supply mode is power supply, and the target graphics card type is an integrated graphics card, the method further comprises:

Receiving switching operation input by a user;

And responding to the switching operation, and switching the type of the target display card from an integrated display card to an independent display card.

4. The method according to claim 1, wherein the method further comprises:

And updating a preset configuration file according to the target display card type, wherein the preset configuration file is used for an executive body to start the APP to be started according to the target display card type in the preset configuration file.

5. An electronic device, comprising: a processor, a memory, and an interface;

The processor, the memory and the interface cooperate to cause the electronic device to perform the method of any of claims 1 to 4.

6. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program which, when executed by a processor, causes the processor to perform the method of any of claims 1 to 4.