A method for multi-core dynamic frequency modulation in a handheld game console
By introducing a lightweight player intent prediction engine and a GPU instruction block sniffer into the handheld game console, the system predicts player actions and precisely adjusts multi-core frequencies, solving game stuttering and overheating issues and improving game smoothness and battery life.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- YEKER INFORMATION TECH CO LTD
- Filing Date
- 2026-07-01
- Publication Date
- 2026-07-31
AI Technical Summary
Existing multi-core dynamic frequency adjustment strategies for handheld game consoles cannot effectively predict the player's intentions, causing the game to stutter during complex operations, and continuous high-frequency operation leads to chip overheating and insufficient battery life.
Employing a lightweight player intent prediction engine and a GPU instruction block sniffer, it predicts player intent by analyzing key operation sequences, pre-increases CPU and GPU frequencies, and combines key features and hash values to identify combo starters, precisely controlling multi-core frequency adjustment.
It achieves rapid response to player input within milliseconds, avoiding game lag, reducing chip heat generation, extending battery life, and improving game smoothness and power utilization efficiency.
Smart Images

Figure CN122479412A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing technology, and in particular to a method for multi-core dynamic frequency adjustment of a handheld game console. Background Technology
[0002] Currently, the multi-core dynamic frequency adjustment strategy for handheld consoles is as follows: 1) Task load parameter: Frequency adjustment is based on the number of background task queues; the more background tasks, the larger this value. 2) Computation load parameter: The more CPU time the current task occupies, the larger this value, typically around 80%. The multi-core strategy updates the strategy table within a certain time interval (usually 3 to 5 seconds) based on the ratio of these two values, adjusting the multi-core operating frequency accordingly. However, the application architecture of handheld games mainly consists of two parts: a foreground game application and a background game application. The foreground application selects and categorizes games; the background application runs the games selected in the foreground.
[0003] This results in less computation for the front-end application and more computation for the back-end application; the back-end game rendering is not timely, which causes lag in the game, especially in eight-axis games, when using special moves and combos. Summary of the Invention
[0004] This invention provides a method for multi-core dynamic frequency adjustment in handheld game consoles, which effectively reduces chip heat generation and extends the console's battery life.
[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, a method for dynamic frequency adjustment of multiple cores in a handheld game console is provided. The method is applied to the handheld game console, and the multiple cores of the handheld game console include a central processing unit (CPU) and a graphics processing unit (GPU). The method includes: when the user operates the handheld game console, the handheld game console obtains the user's current first button operation; the handheld game console determines whether to increase the frequency based on the first button operation; if the frequency is increased, the handheld game console increases the CPU frequency, or increases both the CPU frequency and the GPU frequency, before the user subsequently completes a second button operation after the first button operation.
[0006] Therefore, it can be seen that the CPU or CPU and GPU frequencies are increased in advance after the first button press is detected and before the user completes the second button press. This changes the timing of frequency adjustment from a "passive response" after the load occurs to an "active preparation" before the load arrives, eliminating the second-level response delay inherent in traditional solutions that rely on task load parameters, and fundamentally avoiding screen stuttering during ultimate moves and combos in eight-axis games. At the same time, the frequency increase is triggered only when needed, without having to run at a high frequency continuously like a fixed maximum frequency solution, thus effectively reducing chip heat and extending the handheld's battery life.
[0007] Optionally, the handheld game console has a built-in lightweight player intent prediction engine. The handheld game console obtains the user's current first key operation, including: the player intent prediction engine obtains key operations within a preset duration from the real-time key operation queue, the key operations within the preset duration are the first key operation, the start time of the preset duration is the time corresponding to the latest key operation in the real-time key operation queue, and the end time of the preset duration is before the start time; the handheld game console determines whether to increase the frequency based on the first key operation, including: the player intent prediction engine generates the features of the first key operation based on the first key operation, and determines whether to increase the frequency based on the features of the first key operation.
[0008] Therefore, it can be seen that frequency boosting is determined by extracting a preset-duration sliding window from the real-time button operation queue and using a lightweight player intent prediction engine to extract button features. This mechanism can capture the initial characteristics of player operations within milliseconds, with extremely low computational overhead, and is specifically designed for the resource-constrained environment of handheld consoles. It solves the problem that traditional frequency boosting relies entirely on lagging indicators such as CPU utilization and cannot detect sudden operation intentions, making frequency boosting decisions both fast and accurate, without introducing new delays due to an overly complex analysis process.
[0009] Optionally, when the user's operation of the handheld game console is for a 4-axis game running on the handheld console, the characteristics of the first button operation include the number of button presses, the average button interval duration, and the frequency of button direction changes. Based on the characteristics of the first button operation, determining whether to increase the frequency includes: if the frequency of button direction changes is greater than or equal to a frequency threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency. Alternatively, if the number of button presses is greater than or equal to a number of presses threshold, and the average button interval duration is less than or equal to an interval duration threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency. Or, when the user's operation of the handheld game console is for an 8-axis game running on the handheld console, the characteristics of the first button operation include the hash value of the first button operation. Based on the characteristics of the first button operation, determining whether to increase the frequency includes: the player intent prediction engine determines whether the first button operation is the initiation gesture for a special operation based on the hash value of the first button operation; if the first button operation is the initiation gesture for a special operation, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency.
[0010] Therefore, it can be seen that the frequency of button presses, intervals, and direction changes are used as features for 4-axis games, while the hash value of the starting move is used as a feature for 8-axis games, to distinguish the overclocking logic of the two types of games. 4-axis games only calculate CPU load characteristics to avoid invalid GPU overclocking; 8-axis games identify the starting move of the combo through hash matching to accurately predict GPU-intensive ultimate moves. This classification process makes the frequency adjustment strategy highly matched with the actual game load, ensuring the smoothness of complex games while avoiding unnecessary power consumption and heat generation in simple games.
[0011] Optionally, the player intent prediction engine determines whether the first key press operation is the starting move for a special operation based on the hash value of the first key press operation. This includes: the player intent prediction engine determining whether there is a hash value in the hash value library of the 8-reel game currently being operated by the user that matches the hash value of the first key press operation; wherein, each hash value in the hash value library of the 8-reel game corresponds to a starting move for a special operation, and different 8-reel games contain different hash values in their hash value libraries. If there is a hash value in the hash value library of the 8-reel game that matches the hash value of the first key press operation, then the first key press operation is the starting move for a special operation; if there is no hash value in the hash value library of the 8-reel game that matches the hash value of the first key press operation, then the first key press operation is not the starting move for a special operation; wherein, the time required for the user to complete the starting move for the special operation matches a preset time.
[0012] Therefore, by configuring a dedicated hash value library for each move's starting pattern for different 8-axis games, the prediction engine compares moves on a game-by-game basis when matching starting patterns. This prevents misjudgments of the same directional sequence across different games; for example, it accurately distinguishes between a slow-paced starting move in Street Fighter and a fast-paced starting move in King of Fighters. Game-level granularity significantly improves prediction accuracy, reduces unnecessary power consumption caused by false triggering of frequency upsampling, and ensures that the prediction time window precisely matches the actual move execution rhythm of each game, further enhancing frequency tuning accuracy.
[0013] Optionally, the CPU includes a performance core processing unit, in which a player intent prediction engine is built-in, and the performance core processing unit is directly bound to the user's input.
[0014] Therefore, the player intent prediction engine is fixedly deployed on the CPU's performance core processing unit and directly bound to user input. The performance core boasts the highest single-threaded responsiveness and the lowest interrupt handling latency, ensuring that the calculation for initial key recognition can be completed within a very short time after a key press interruption. This design avoids the limitations of traditional solutions where frequency adjustment logic is distributed across multiple cores and affected by task scheduling delays, providing a deterministic, low-latency execution environment for "immediate prediction and frequency boosting after the first key press."
[0015] Optionally, when the user's operation of the handheld game console is an operation performed by the user for an 8-axis game running on the handheld game console, the second button operation is a complete special operation.
[0016] Therefore, in 8-axis games, the second button operation clearly refers to the complete special operation performed by the player (such as the entire combo command). This makes the definition of the boost window "after the first button operation and before the second button operation" clear and unambiguous. The system can immediately boost the frequency the moment the starting move is recognized, ensuring that the CPU and GPU frequencies are at a high level throughout the entire execution of the ultimate move, fully covering the entire process from command judgment to effect rendering, and eliminating any possible stuttering frames.
[0017] Optionally, when the user's operation of the handheld game console is an operation performed by the user on a 4-axis game running on the handheld game console, the handheld game console is configured to only need to increase the CPU frequency; increasing the CPU frequency includes: if the button direction change frequency is greater than or equal to a frequency threshold, and the number of button presses is less than a number of button presses threshold, then the player intent prediction engine sends a first instruction to the CPU, the first instruction instructing the CPU to increase its frequency to a first frequency; if the button direction change frequency is greater than or equal to a frequency threshold, and the number of button presses is greater than or equal to a number of button presses threshold, then the player intent prediction engine sends a second instruction to the CPU, the second instruction instructing the CPU to increase its frequency to a second frequency; if the number of button presses is greater than or equal to a number of button presses threshold, and the average button press interval duration is less than or equal to an interval duration threshold, then the player intent prediction engine sends a third instruction to the CPU, the third instruction instructing the CPU to increase its frequency to a third frequency; wherein, the first frequency is less than the second frequency, and the second frequency is less than the third frequency.
[0018] Therefore, in 4-axis games, the CPU frequency is divided into three progressive levels based on the frequency of button direction changes and the density of continuous attacks. The frequency increases to a low level when the player moves quickly, to a medium level when moving quickly and attacking in a single burst, and to the highest frequency only when firing rapidly. This refined frequency tier allows performance to be precisely matched to the intensity of the operation, providing sufficient computing power during bursts of rapid-fire attacks while significantly reducing power consumption during low-intensity operations. This avoids the power waste and continuous heat generated by traditional solutions that maintain the same high frequency regardless of the intensity of the operation.
[0019] Optionally, the graphics driver layer of the handheld game console has a built-in GPU instruction block sniffer. When the user's operation of the handheld game console is an operation performed by the user for an 8-axis game running on the handheld game console, the handheld game console is configured to increase the CPU frequency and GPU frequency. Increasing the CPU frequency and GPU frequency includes: the player intent prediction engine sending a CPU upclocking instruction to the CPU, the CPU upclocking instruction instructing the CPU to increase the frequency from the current level to the next level of frequency; and the player intent prediction engine sending a GPU upclocking instruction to the GPU instruction block sniffer; the GPU instruction block sniffer controls the GPU upclocking based on the GPU upclocking instruction and the GPU driver instructions generated by the 8-axis game running on the handheld game console.
[0020] Therefore, in 8-axis games, the player intent prediction engine simultaneously sends upclocking commands to both the CPU and GPU instruction block sniffers. The sniffers then combine this with the actual GPU driver commands to control the GPU upclocking. This two-level collaborative architecture combines "prediction" with "actual measurement." The prediction engine is responsible for seizing the time window, while the sniffers are responsible for verifying the actual rendering load. This ensures that GPU upclocking no longer blindly follows the prediction but is adjusted based on the actual commands to be executed, significantly improving the targeting and energy efficiency of GPU frequency tuning.
[0021] Optionally, the GPU instruction block sniffer controls GPU upscaling based on GPU upscaling instructions and GPU driving instructions generated by the 8-axis game running on the handheld gaming console. This includes: the GPU instruction block sniffer upscaling the GPU's memory frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency from the current level to the next level based on the GPU upscaling instructions; subsequently, if the GPU instruction block sniffer detects that the GPU driving instruction is texture bombing type, the GPU instruction block sniffer continues to upscale the memory frequency to the next level while maintaining the shader core frequency, geometry processing unit frequency, and raster unit frequency; if the GPU instruction block sniffer detects that the GPU driving instruction is complex shading type, the GPU instruction block sniffer continues to upscale the shader core frequency to the next level after that while maintaining the memory frequency. The GPU instruction block sniffer detects that the GPU driver instruction is of the high vertex load type, and then increases the geometry processing unit frequency to the next level while maintaining the memory frequency, shader core frequency, and raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is of the post-processing effects type, then increases the memory frequency and shader core frequency to the next level while maintaining the geometry processing unit frequency and raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is of the particle explosion type, then increases the memory frequency and raster unit frequency to the next level while maintaining the shader core frequency and geometry processing unit frequency.
[0022] Therefore, the GPU instruction block sniffer first boosts all GPU modules by one level based on the prediction engine's instructions as a momentary safety margin. Then, it analyzes the actual types of GPU driver instructions arriving and, for different loads such as textures, shaders, vertices, post-processing, and particles, only boosts the truly stressed modules (such as memory controllers or shader cores) to a higher level, while keeping the rest of the modules at their original levels. This "overall safety margin first, then targeted boost" strategy ensures both fast upscaling response and precisely focuses additional power consumption on key modules, avoiding the huge power consumption and heat generated by running all modules at their highest frequencies.
[0023] Optionally, after the GPU instruction block sniffer increases the GPU's memory frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency from the current level to the next level based on the GPU upclocking instruction, the method further includes: if the player intent prediction engine determines that the user has not entered a complete special operation, the player intent prediction engine sends a downclocking instruction to the CPU and a GPU downclocking instruction to the GPU instruction block sniffer.
[0024] Therefore, when the player intent prediction engine determines that the user has failed to complete a specific operation (i.e., prediction failure), it immediately sends a frequency reduction instruction to the CPU and a frequency reduction instruction to the GPU instruction block sniffer. This rapid rollback mechanism ensures that the frequency boosted due to misjudgment can be promptly reversed, preventing high-frequency idling from continuously generating heat and consuming power. Compared to traditional solutions that rely on timers with long periods of inactivity to reduce frequency, this solution minimizes the power consumption cost of incorrect predictions, further improving battery life in actual use.
[0025] In a second aspect, a handheld game console is provided, comprising: a processor and a memory; the memory is used to store a computer program, which, when executed by the processor, causes the handheld game console to perform the method described in the first aspect.
[0026] In one possible design, the handheld game console described in the second aspect may further include a transceiver. This transceiver may be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the handheld game console described in the second aspect and other handheld game consoles.
[0027] In the embodiments of the present invention, the handheld game console described in the second aspect can be a terminal, or a chip (system) or other component or assembly disposed in the terminal, or a system containing the terminal.
[0028] Thirdly, a computer-readable storage medium is provided, comprising: a computer program or instructions; when the computer program or instructions are executed on a computer, the computer causes the computer to perform the method described in the first aspect. Attached Figure Description
[0029] Figure 1 A schematic diagram of the architecture of a handheld game console provided in an embodiment of the present invention. Figure 1 ; Figure 2 A schematic diagram of the architecture of a handheld game console provided in an embodiment of the present invention. Figure 2 ; Figure 3 A flowchart illustrating the multi-core dynamic frequency modulation method for a handheld game console provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a handheld game console provided in an embodiment of the present invention. Detailed Implementation
[0030] The technical solution of the present invention will now be described with reference to the accompanying drawings.
[0031] In this embodiment of the invention, descriptions such as "when," "under the circumstances," "if," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not limited to a specific time. They do not require the device to make a judgment action during implementation, nor do they imply any other limitations.
[0032] To facilitate understanding of the embodiments of the present invention, firstly, using Figure 1 The example shown is a handheld game console. Figure 1 As shown, the handheld game console may include a central processing unit (CPU) and a graphics processing unit (GPU).
[0033] The CPU can be a multi-core processor, including at least one performance core (P-core) and at least one energy-efficient core (E-core). The performance core has a high clock speed and single-threaded processing capability, suitable for latency-sensitive computing tasks; the energy-efficient core has low power consumption, suitable for background tasks and lightweight workloads. The GPU can be a graphics processing unit that supports component-level independent dynamic frequency adjustment, containing multiple functional modules with independently adjustable operating frequencies, such as memory controllers, shader cores, geometry processing units, and raster units.
[0034] like Figure 2 As shown, the handheld game console incorporates a lightweight player intent prediction engine. This engine primarily analyzes key press sequences in real-time during player actions, identifying the starting gesture before the player completes a full action (such as a combo command). This allows it to anticipate upcoming performance demands and trigger a frequency boost. Specifically, since the CPU includes performance cores (P-cores) and energy-efficient cores (E-cores), the player intent prediction engine is integrated into the performance core. This performance core is directly linked to the user's input. Therefore, when a key press interruption occurs, the engine can acquire and analyze the key event with minimal latency, ensuring the frequency boost command is issued before the full action is completed. This eliminates response lag caused by passively waiting for load increases.
[0035] Furthermore, the handheld game console's graphics driver layer incorporates a GPU instruction block sniffer. The graphics driver layer is an intermediate software layer located between the game application and the GPU hardware. The game application submits rendering commands by calling graphics interfaces (such as OpenGL ES or Vulkan). The graphics driver layer receives these calls, compiles them, and packages them into instruction blocks that the GPU can directly execute. The advantage of placing this GPU instruction block sniffer in the graphics driver layer is that, being located after the instruction block is packaged but before it is submitted to the GPU hardware for execution, it can directly obtain instruction blocks containing complete rendering type information. This information is complete, and the overhead of interception and analysis is extremely low. Simultaneously, the analysis results can be delivered to the frequency modulation decision module before the actual execution of the instruction block, ensuring that directional frequency modulation is synchronized with rendering execution in timing, avoiding frequency upsampling lag. Furthermore, a GPU includes multiple modules, such as a memory controller, shader cores, geometry processing units, and raster units. The GPU instruction block sniffer is mainly used to precisely control the frequency increase or decrease of the above multiple modules. For example, by analyzing the instruction block type in the current frame, it can identify the specific functional module that is actually under pressure and only perform frequency increase or decrease operations on that specific module, while keeping the frequency of other modules unchanged or reverting them, thereby limiting power consumption to the minimum necessary level without affecting rendering performance.
[0036] Figure 3 This is a flowchart illustrating the method provided in an embodiment of the present invention. The multi-core dynamic frequency modulation method for this handheld game console is applicable to the aforementioned handheld game console. The specific process is as follows: S301: When the user operates the handheld game console, the handheld game console obtains the user's current first button operation.
[0037] The first button operation can be the sequence of operations that the player inputs through the physical buttons or joystick of the handheld game console during the game.
[0038] For 4-axis games, the first button operation can be a quick jump using the directional keys, such as instantly switching from "left" to "right"; it can also be a series of rapid presses of the attack button, such as pressing the A button twice within 80 milliseconds. 4-axis games refer to games that only support input in four orthogonal directions: up, down, left, and right. Their joysticks or directional keys do not have the hardware capability to simultaneously trigger adjacent directional switches, making it impossible to input diagonal commands. Typical 4-axis games include maze games and platforming games, whose controls primarily involve directional movement and single attacks, without complex combo inputs.
[0039] For 8-axis games, the first button press can be a sliding motion of the joystick from a single direction into an angled area, such as sliding from "down" to "down right" or from "forward" to "forward right." It's important to note that in 8-axis games, the first button press is not the complete action performed by the player, but rather the initial part of the complete action, i.e., the "starting stance" phase. Taking fighting games as an example, if a player intends to perform a special action requiring a combo input (such as ↓↘→↘↓↙← + punch), the player first slides the joystick from down to down right; this sequence of directional changes during the sliding motion is the first button press. 8-axis games are games that support input in eight directions (up, down, left, right, and four diagonal directions ↖, ↗, ↘, ↙). The joystick can simultaneously activate two adjacent microswitches to generate diagonal signals. Typical 8-axis games include fighting games and beat 'em up games. Their core gameplay involves a large number of special operations that require combo input. These special operations are composed of a series of directional changes and attack buttons.
[0040] In the specific implementation, the acquisition of the aforementioned first key operation is performed by the player intent prediction engine. The player intent prediction engine retrieves key operations within a preset duration from the real-time key operation queue. The real-time key operation queue is a circular buffer maintained by the key driver layer. After a key hardware triggers an interrupt, the interrupt handler writes each key event (including event type and microsecond-level timestamp) sequentially into this queue. The key operations within the preset duration are the first key operations. The start time of the preset duration is the time corresponding to the latest key operation in the real-time key operation queue, and the end time of the preset duration is before the start time. In other words, the preset duration can be understood as a sliding window that slides as the latest key operations are continuously added to the real-time key operation queue. This sliding window only retains the key history within the most recent very short period of time, and its time span is designed to fully capture the player's current action's initiation gesture, while excluding earlier historical key operations that are unrelated to the current action's intent. For example, in a 4-axis game scenario, the preset duration can be set to 50 milliseconds, which is sufficient to cover the button sequence of two quick combos or one directional jump; in an 8-axis game scenario, the preset duration can be set to 80 to 100 milliseconds, which is sufficient to cover the time required for a short combo starter (such as sliding from "down" to "down right").
[0041] By acquiring the first button operation as described above, this solution can capture the initial characteristic information that can be used for subsequent prediction when the player's operation intention is initially revealed but the complete operation has not yet been completed, thus providing timely and accurate input basis for subsequent frequency increase decisions.
[0042] The S302 handheld game console determines whether to upclock based on the first button operation.
[0043] The player intent prediction engine generates features based on the first key press, and determines whether to increase the frequency based on these features. The features generated based on the first key press vary depending on the game type, and are explained in two cases below.
[0044] Scenario 1: 4-axis game When a user operates a handheld game console in the context of a 4-axis game, the characteristics of the first button press include the number of presses, the average interval between presses, and the frequency of directional changes. In other words, the player intent prediction engine statistically analyzes the first button presses captured within the sliding window, extracting quantitative indicators that characterize the intensity of the operation, such as the number of times the player consecutively presses the attack button, the average time interval between these consecutive presses, and whether the directional keys experienced significant jumps (e.g., a 180-degree rotation in a very short time).
[0045] Therefore, the player intent prediction engine determines whether to increase the frequency based on the above characteristics. Specifically, if the frequency of key direction changes is greater than or equal to a frequency threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not. Alternatively, if the number of key presses is greater than or equal to a number of key presses threshold, and the average key press interval is less than or equal to an interval duration threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not. The above two sets of judgment conditions are related by "OR," and satisfying either set triggers a frequency increase.
[0046] For example, the frequency threshold can be set to: detecting at least one 180-degree directional flip within a 50-millisecond sliding window. This indicates that the player is performing a rapid turn or dodge, which will be followed by an attack, requiring increased computing power in advance to avoid response latency. For example, the number of times threshold can be set to 2, and the interval duration threshold can be set to 80 milliseconds. When there are at least 2 attack button presses within the window and the average interval is less than 80 milliseconds, it indicates that the player is performing a high-speed rapid-fire attack. The instantaneous computational load of such an operation is much higher than that of a normal single attack, so the frequency needs to be increased in advance to ensure smooth gameplay.
[0047] Scenario 2: 8-axis game When a user operates a handheld game console to play an 8-axis game, the characteristics of the first button press include its hash value. This hash value is a numerical value calculated using a preset hash function based on a snapshot of the direction change sequence during the first button press, used to quickly identify the type of the sequence. For example, the direction sequence extracted from the sliding window (such as [downward, downward right]) can be input into the hash function to obtain the corresponding hash value.
[0048] Therefore, the player intent prediction engine can determine whether the first button press is the starting move for a special operation based on its hash value. If the first button press is the starting move for a special operation, the player intent prediction engine will increase the frequency; otherwise, it will not. It should be noted that in 8-axis fighting games or beat 'em up games, the starting moves for special operations (such as releasing a special move or super special move) are usually not presented as a single button press or a single directional change. Instead, they are represented as a specific, identifiable directional change pattern, such as a continuous sequence of directional changes where the joystick slides from directly downwards, then to the lower right, and finally to directly forwards. These directional sequences of starting moves, after being calculated by a hash function, correspond to a unique hash value.
[0049] In one possible implementation, the player intent prediction engine can determine whether there is a hash value in the hash value library of the 8-reel game currently being played that matches the hash value of the first key press. Each hash value in the 8-reel game's hash value library corresponds to a special action's starting move, and different 8-reel games contain different hash values in their respective hash value libraries. This is because different 8-reel games define different types of special actions and their corresponding commands. For example, a fighting game might primarily use "↓↘→" type commands for special actions, while a beat-'em-up game might primarily use "↓↑" type commands. Therefore, each game's starting move hash value library needs to be configured independently. If there is a hash value in the 8-reel game's hash value library that matches the hash value of the first key press, it means that the first key press is a special action's starting move; if there is no hash value in the 8-reel game's hash value library that matches the hash value of the first key press, it means that the first key press is not a special action's starting move. The time required for a user to complete a special operation is matched with the preset time. In other words, the time span setting of the sliding window has fully considered the completion time of typical starting actions to ensure that the directional sequence of the starting actions can be completely captured within the window.
[0050] For example, in an 8-axis game scenario, the preset duration is set to 80 to 100 milliseconds. The player slides the joystick from "straight down" to "down right" (i.e., ↓→↘). This directional sequence snapshot is hashed to obtain a hash value. If a corresponding entry exists in the currently loaded hash value library (e.g., corresponding to a special move starting with ↓↘→), the match is successful, and the player intent prediction engine determines to increase the frequency. If the player only slightly shakes the joystick in place, and the resulting directional sequence has no matching entry in the hash value library, the player intent prediction engine determines not to increase the frequency. Through this hash value-based matching mechanism, this solution can accurately predict the player's intention based solely on the directional sequence of the initial movement before the player completes a full special operation command, providing a reliable basis for subsequent early frequency increases.
[0051] S303, if the frequency is increased, the handheld game console will increase the CPU frequency, or increase the CPU frequency and GPU frequency, before the user performs the second button operation after the first button operation.
[0052] It should be noted that the prerequisite for increasing the frequency during frequency upscaling is that the frequency corresponding to the current level is not the highest frequency. If the current frequency is already at the highest level, the current frequency will remain unchanged, and no frequency upscaling operation will be performed.
[0053] For 4-axis games, where the user is controlling the handheld game console in a 4-axis game, the second button operation can be a single attack button pressed immediately after a directional jump, or a subsequent continuous attack button during high-speed rapid-fire. For example, in platforming games, pressing the jump button while moving quickly laterally to clear obstacles is the second button operation; similarly, in maze games, pressing the attack button immediately after a quick turn to eliminate enemies is the second button operation.
[0054] For 8-axis games, where the user's operation of the handheld gaming console is specific to the 8-axis game being played, the second button operation is a complete special action. Taking fighting games as an example, if the first button operation is the initial motion of sliding the joystick from "down" to "down right," then the second button operation is the player's subsequent complete combo command (e.g., ↓↘→↘↓↙← + punch), including all remaining directional changes after the initial motion and the final press of the attack button.
[0055] The following explains the specific implementation of increasing the frequency in two different scenarios.
[0056] Scenario 1: 4-axis game When the user operates the handheld gaming console to play a 4-axis game, the GPU is usually not a performance bottleneck because the rendering load of 4-axis games is relatively low. Therefore, the handheld gaming console is configured to only need to increase the CPU frequency.
[0057] CPU frequency levels, from lowest to highest, are: base frequency (minimum frequency), first frequency, second frequency, and third frequency (maximum frequency). The base frequency can be set to 800 MHz, serving as the default frequency for game operation; the first frequency can be set to 1.0 GHz, suitable for light workloads; the second frequency can be set to 1.2 GHz, suitable for medium workloads; and the third frequency can be set to 1.4 GHz, suitable for heavy workloads.
[0058] Specifically, the player intent prediction engine sends the appropriate level of upclocking command to the CPU based on the characteristic conditions used to determine the upclocking in S302: If the frequency of key presses changing direction is greater than or equal to a frequency threshold, and the number of key presses is less than a number of key presses, the player intent prediction engine sends a first instruction to the CPU. This first instruction instructs the CPU to increase its frequency from the current frequency to a first frequency. For example, if the player only performs a quick turn (directional jump) but has not yet pressed the attack key, the system predicts that the player may be about to launch an attack and increases the CPU frequency from the base frequency of 800 MHz to 1.0 GHz to provide light computing power.
[0059] If the frequency of key press direction changes is greater than or equal to a frequency threshold, and the number of key presses is greater than or equal to a number of key presses threshold, the player intent prediction engine sends a second instruction to the CPU. This second instruction instructs the CPU to increase its frequency from the current frequency to a second frequency. For example, if a player quickly turns around and then presses the attack key at least once, completing a "turn + attack" combo, the load is higher than that of simple movement, and the system will increase the CPU frequency to 1.2 GHz.
[0060] If the number of key presses is greater than or equal to the key press threshold, and the average key press interval is less than or equal to the interval threshold, the player intent prediction engine sends a third instruction to the CPU. This third instruction instructs the CPU to increase its frequency from the current frequency to a third frequency. For example, if a player presses the attack button twice within 80 milliseconds, entering a high-speed burst attack state, the CPU's instantaneous computational load is at its highest. The system will then directly increase the CPU frequency to 1.4 GHz to ensure smooth gameplay during the burst attack.
[0061] It should be noted that the above frequency increase uses a direct jump method, meaning that the CPU frequency is directly increased to the corresponding target level based on the trigger conditions, without going through intermediate levels for gradual transition, thus minimizing response latency during the frequency increase process. Furthermore, if the current frequency is already at or above the frequency corresponding to the target level, the frequency increase will not be performed.
[0062] Scenario 2: 8-axis game When the user operates the handheld gaming console to play an 8-axis game, the complex special effects rendering of the 8-axis game places high demands on the GPU's computing power. Therefore, the handheld gaming console is configured to increase the CPU and GPU frequencies.
[0063] Regarding the CPU upscaling, the player intent prediction engine sends a CPU upscaling command to the CPU, instructing the CPU to increase its frequency from the current level to the next level. The CPU frequency levels in 8-axis games can use the four-level settings (base frequency, first frequency, second frequency, third frequency) of 4-axis games. The upscaling trigger conditions and upscaling magnitude can be found in the relevant description in Case 1, and will not be repeated here.
[0064] For the GPU upclocking part, the player intent prediction engine sends GPU upclocking commands to the GPU instruction block sniffer. The GPU instruction block sniffer controls the GPU upclocking based on the GPU upclocking commands and the GPU drive commands generated by the 8-axis game running on the handheld console.
[0065] It's important to note that each functional module within a GPU can have its own independent frequency level classification, and the frequency values of different modules can vary within the same level. For example, the memory controller's frequency level can be set to 300 MHz, 600 MHz, or 900 MHz; the shader core's frequency level can be set to 200 MHz, 500 MHz, or 800 MHz; and the geometry processing unit and raster unit also have their own frequency levels. The phrase "promotion from the current level to the next level" in the following text refers to each module moving from level N to level N+1 within its own frequency level system, rather than uniformly setting it to the same value.
[0066] Upon receiving a GPU upclocking command, the GPU instruction block sniffer first performs an overall upclock, which means uniformly upclocking the GPU's memory controller, shader cores, geometry processing units, and raster units from their current levels to the next level. For example, if the memory controller is currently at 600 MHz (Level 1) and the shader cores are currently at 500 MHz (Level 1), they will be upclocked to 900 MHz (Level 2) and 800 MHz (Level 2) respectively. This overall upclocking action aims to establish a safe operating frequency as quickly as possible.
[0067] After the overall upsampling is complete, the GPU instruction block sniffer further analyzes the characteristics of the packaged GPU driver instruction blocks within the current frame, determines the instruction type based on the characteristics, and performs targeted fine-tuning upsampling. The determination characteristics of the five instruction types and their corresponding fine-tuning strategies are explained below: Texture bombing: If the GPU instruction block sniffer detects that the number of texture binding operations in the instruction block of the current frame exceeds a preset texture binding count threshold (e.g., the number of times textures with a resolution greater than 2048×2048 pixels are bound in a single frame is greater than or equal to 3), then the instruction type of the current frame is determined to be texture bombing. The bottleneck for this type of load is concentrated in memory bandwidth. At this time, the GPU instruction block sniffer continues to increase the frequency of the memory controller to the next level, while keeping the shader core frequency, geometry processing unit frequency, and raster unit frequency unchanged at the current level.
[0068] Complex Shading Type: If the GPU instruction block sniffer detects that the bound shader program in the instruction block of the current frame is marked as high complexity (e.g., the number of instructions in the shader program exceeds a preset instruction count threshold, or the ratio of mathematical operation instructions and branch instructions in the shader program exceeds a preset ratio threshold), then the instruction type of the current frame is determined to be complex shading type. The bottleneck for this type of load is concentrated in the arithmetic logic unit of the shader core. At this time, the GPU instruction block sniffer continues to increase the shader core frequency to the next level, while maintaining the memory controller frequency, geometry processing unit frequency, and raster unit frequency at the current level.
[0069] High Vertex Load Type: If the GPU instruction block sniffer detects that the number of vertices in a single draw call exceeds a preset vertex count threshold (e.g., more than 50,000 vertices in a single draw call), or the total number of vertices in all draw calls within the current frame exceeds a preset cumulative vertex count threshold (e.g., more than 200,000 vertices), then the instruction type of the current frame is determined to be high vertex load type. The bottleneck for this type of load is concentrated in the geometry processing unit. In this case, the GPU instruction block sniffer continues to increase the geometry processing unit frequency to the next level, while maintaining the memory controller frequency, shader core frequency, and raster unit frequency at the current level.
[0070] Post-processing effects type: If the GPU instruction block sniffer detects at least two of the following characteristics in the instruction block of the current frame: binding an off-screen rendering target, drawing a quadrilateral covering the entire screen, or enabling a specific blending mode, then the instruction type of the current frame is determined to be post-processing effects type. This type of workload has high requirements for memory bandwidth and shader core computing power, but almost no requirements for geometry processing. At this time, the GPU instruction block sniffer continues to increase the memory controller frequency and shader core frequency to the next level, while maintaining the geometry processing unit frequency and raster unit frequency at the current level.
[0071] Particle Explosion Type: If the GPU instruction block sniffer detects the following characteristics in the instruction block of the current frame: the number of sprite draw calls for primitive types exceeds a preset particle draw count threshold (e.g., more than 20 sprite draw calls in a single frame), and opacity blending is enabled, then the instruction type of the current frame is determined to be particle explosion type. This type of load requires the raster unit to efficiently convert a large number of tiny primitives into screen pixels, while also requiring memory bandwidth to support high-frequency mixed read and write operations. In this case, the GPU instruction block sniffer continues to increase the memory controller frequency and raster unit frequency to the next level, while maintaining the shader core frequency and geometry processing unit frequency at the current level.
[0072] In addition, after the GPU instruction block sniffer increases the GPU's memory controller frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency from the current level to the next level based on the GPU upclocking instruction, this method also includes a rollback mechanism for predicting failures.
[0073] Specifically, if the player intent prediction engine detects that the user has not completed a complete special operation (i.e., the second button operation has not occurred) after determining the frequency increase and issuing CPU and GPU frequency increase commands, the player intent prediction engine determines that this frequency increase prediction is a misjudgment. Situations that may lead to misjudgment include: after the player inputs the starting move (such as sliding the joystick from "down" to "down right"), they abandon the subsequent combo operation midway due to changes in the game situation and release the direction key; or if no expected subsequent directional change is detected within 50 milliseconds after the starting move (such as continuing to slide to "forward"), it indicates that the joystick slide may have been just a normal movement operation, rather than the starting move for a special operation.
[0074] In this scenario, the player intent prediction engine sends a CPU downclocking command to the CPU, instructing it to roll back its frequency to the level before the overclock. Simultaneously, the player intent prediction engine sends a GPU downclocking command to the GPU instruction block sniffer, which then rolls back the GPU's memory controller frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency to their respective levels before the overall overclock. For example, if the initial intention is detected in S301, the overclock is confirmed in S302, and the CPU frequency has been increased from base frequency to 1.4 GHz and all GPU modules have been uniformly increased by one level in S303, but the player intent prediction engine determines that the prediction failed, the CPU frequency will drop from 1.4 GHz back to base frequency, and the frequencies of all GPU modules will revert from the overclocked level to the level before the overclock. Through this rapid rollback mechanism, the system can promptly cancel the frequency increase caused by misjudgment, preventing high-frequency idling from continuously generating power consumption and heat.
[0075] The following provides supplementary explanation of the frequency reduction strategy in this method. In addition to the immediate rollback triggered by the predicted failure mentioned above, this method also includes a stepped frequency reduction mechanism based on the operation interval timeout, so as to achieve a complete closed loop of frequency increase and decrease.
[0076] The basic principle of frequency reduction is as follows: if the player intent prediction engine does not detect a first key press of the same type as triggering frequency increase within a preset duration, the CPU and / or GPU frequencies are gradually reduced according to frequency levels until they return to the base frequency. Frequency reduction adopts a gradual gradient decrease method, reducing by one level at a time. There is a preset frequency reduction interval between two adjacent frequency reductions to avoid drastic frequency fluctuations that could cause screen stuttering or increased system overhead.
[0077] Scenario 1: Frequency throttling in 4-axis games When the user operates the handheld game console to play a 4-axis game, the 4-axis game only involves CPU upclocking, and downclocking only affects the CPU.
[0078] Specifically, after the CPU is boosted to a certain level according to S303, if the player's intention prediction engine does not detect any first key operation that meets the boost conditions (i.e., no directional jump, and no consecutive attack key presses that meet the number and interval thresholds) within a preset downclocking wait time (e.g., 30 seconds), the CPU frequency will be reduced by one level from the current level. If, after being reduced to the new level, another downclocking wait time passes and still no first key operation that meets the boost conditions occurs, the frequency will be reduced by another level, and so on in a step-by-step manner, until it returns to the base frequency.
[0079] For example, suppose the CPU is currently at its third frequency (1.4 GHz) due to rapid-fire gameplay. After the rapid-fire ends, the player begins to move slowly or remain stationary to observe. If no operation that meets the frequency increase condition occurs within 30 seconds, the CPU drops from 1.4 GHz to the second frequency (1.2 GHz). If no frequency increase condition is triggered after another 30 seconds, it drops from 1.2 GHz to the first frequency (1.0 GHz), and after another 30 seconds, it drops to the base frequency (800 MHz). After dropping to the base frequency, it stops decreasing and is maintained as the minimum guaranteed frequency for game operation.
[0080] Scenario 2: throttling in 8-axis games When the user operates the handheld game console to play an 8-axis game, both the CPU and GPU participate in upclocking, so both need to be processed when downclocking.
[0081] Regarding the CPU downclocking, the CPU downclocking logic in 8-axis games is the same as that in 4-axis games, which is based on the operation interval timeout during the downclocking waiting time, and gradually decreases in a step-by-step manner until it is restored to the base frequency. This will not be elaborated here.
[0082] Regarding GPU downclocking, after the GPU is upclocked to a certain level based on S303 and / or finely tuned, if the player's intention prediction engine does not detect any special operation initiation within a preset downclocking wait time (e.g., 30 seconds), the GPU instruction block sniffer will reduce the GPU's memory controller frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency by one level from their current levels. If no initiation occurs after another downclocking wait time, the frequency will continue to decrease gradually until it returns to the base frequency.
[0083] For example, suppose the GPU modules are currently at a higher frequency level due to a special operation. After the special operation ends, the player only performs normal movement and single attacks, without inputting any combo inputs. After 30 seconds, each GPU module decreases by one level; after another 30 seconds, it decreases by another level, until all modules return to their base frequency.
[0084] Furthermore, considering that in 8-axis games there may be scenarios where players perform normal operations for extended periods without executing combos, this method introduces a frame rate fallback detection mechanism as an auxiliary criterion for judging GPU frequency reduction, in addition to the frequency reduction waiting time. Specifically, the GPU instruction block sniffer can detect the rendering refresh rate every preset frame rate detection cycle (e.g., 5 seconds). If the refresh rate is consistently above the preset smooth frame rate threshold (e.g., 30 frames / second) for a preset number of consecutive times (e.g., 6 times, for a total of 30 seconds), it is confirmed that the current GPU frequency has redundancy, and it can be reduced by one level according to the above-mentioned stepped frequency reduction strategy. If, in any detection cycle after frequency reduction, the refresh rate is lower than the preset stuttering frame rate threshold (e.g., 25 frames / second), it indicates that the frequency reduction is excessive, and the frequency of each GPU module must be immediately restored to the level before frequency reduction, and this level is set as the minimum guaranteed frequency during the current game operation, and no further reduction is allowed.
[0085] It should be noted that the above-mentioned downclocking waiting time, frame rate detection cycle, smooth frame rate threshold, and stuttering frame rate threshold are all exemplary parameters and can be adapted and adjusted according to actual hardware capabilities and game type.
[0086] By combining the aforementioned stepped frequency reduction strategy with the rollback mechanism for predicted failures, this method achieves "rapid boost and guaranteed experience" on the frequency boosting side and "slow fall and energy saving" on the frequency reduction side. At the same time, it can "correct errors in real time and avoid waste" when prediction errors occur, thus forming a complete dynamic balance closed loop between performance supply and power consumption control.
[0087] In summary, after detecting the first button press and before the user completes the second button press, the CPU or CPU and GPU frequencies are increased in advance. This changes the timing of frequency adjustment from a "passive response" after the load occurs to an "active preparation" before the load arrives, eliminating the second-level response delay inherent in traditional solutions that rely on task load parameters, and fundamentally avoiding screen stuttering during ultimate moves and combos in eight-axis games. Furthermore, the frequency increase is triggered only when needed, unlike fixed-maximum-frequency solutions that operate at high frequencies continuously, thus effectively reducing chip heat and extending the handheld's battery life.
[0088] Figure 4 This is a schematic diagram of the structure of a handheld game console provided in an embodiment of the present invention. Figure 4 As shown, the handheld game console 400 may include a processor 401. Optionally, the handheld game console 400 may also include a memory 402 and / or a transceiver 403. The processor 401 is coupled to the memory 402 and the transceiver 403, for example, via a communication bus.
[0089] The following is combined Figure 4 A detailed introduction to the various components of the GameSpot 400 handheld console: The processor 401 is the control center of the handheld game console 400. It can be a single processor or a collective term for multiple processing elements. For example, the processor 401 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).
[0090] Optionally, the processor 401 can perform various functions of the handheld game console 400 by running or executing software programs stored in the memory 402 and calling data stored in the memory 402.
[0091] In a specific implementation, as one example, processor 401 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 are shown in the diagram.
[0092] In a specific implementation, as one example, the handheld game console 400 may also include multiple processors. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).
[0093] The memory 402 is used to store the software program that executes the solution of the present invention, and is controlled by the processor 401 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.
[0094] Optionally, the memory 402 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 402 may be integrated with the processor 401 or may exist independently and be connected via the interface circuit of the handheld game console 400. Figure 4 (Not shown in the image) is coupled to processor 401, but this embodiment of the invention does not specifically limit this.
[0095] Transceiver 403 is used for communication with other handheld game consoles.
[0096] Alternatively, transceiver 403 may include a receiver and a transmitter. Figure 4 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.
[0097] Alternatively, the transceiver 403 can be integrated with the processor 401, or it can exist independently and be connected via the interface circuit of the handheld game console 400. Figure 4 (Not shown in the image) is coupled to processor 401, but this embodiment of the invention does not specifically limit this.
[0098] Understandable, Figure 4The structure of the handheld game console 400 shown in the figure does not constitute a limitation on the handheld game console. An actual handheld game console may include more or fewer parts than shown, or combine certain parts, or have different part arrangements.
[0099] Furthermore, the technical effects of the game console 400 can be referred to the technical effects of the methods described in the above embodiments, and will not be repeated here.
[0100] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0101] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).
[0102] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.
[0103] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
Claims
1. A method for multi-core dynamic frequency modulation of a handheld game console, characterized in that, The method is applied to a handheld game console, wherein the handheld game console has multiple cores including a central processing unit (CPU) and a graphics processing unit (GPU), and the method includes: When the user operates the handheld game console, the handheld game console acquires the user's current first button operation; The handheld game console determines whether to increase the frequency based on the operation of the first button; If the frequency is increased, the handheld game console increases the frequency of the CPU or increases the frequency of both the CPU and the GPU before the user performs the second button operation after the first button operation. The handheld game console has a built-in lightweight player intent prediction engine. The handheld game console obtains the user's current first key press operation, including: The player intent prediction engine obtains key operations within a preset duration from the real-time key operation queue. The key operations within the preset duration are the first key operations. The start time of the preset duration is the time corresponding to the latest key operation in the real-time key operation queue. The end time of the preset duration is before the start time. The handheld game console determines whether to upclock based on the first button operation, including: The player intent prediction engine generates features of the first key operation based on the first key operation, and determines whether to increase the frequency based on the features of the first key operation. When the user's operation of the handheld game console is an operation performed by the user on a 4-axis game running on the handheld game console, the characteristics of the first button operation include the number of button presses, the average button interval duration, and the frequency of button direction changes. The step of determining whether to increase the frequency based on the characteristics of the first button operation includes: If the frequency of the key direction change is greater than or equal to the frequency threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency. Alternatively, if the number of key presses is greater than or equal to the number of key presses threshold, and the average key press interval duration is less than or equal to the interval duration threshold, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency. Alternatively, if the user's operation of the handheld game console is an operation of an 8-axis game running on the handheld game console, the feature of the first button operation includes the hash value of the first button operation. The step of determining whether to increase the frequency based on the characteristics of the first button operation includes: The player intent prediction engine determines whether the first key operation is the initiation mode of a special operation based on the hash value of the first key operation. If the first key operation is the initiation mode of a special operation, the player intent prediction engine determines to increase the frequency; otherwise, it does not increase the frequency.
2. The method according to claim 1, characterized in that, The player intent prediction engine determines whether the first key press is the initiation gesture for a special operation based on the hash value of the first key press, including: The player intent prediction engine determines whether there is a hash value in the hash value library of the 8-axis game currently being operated by the user that matches the hash value of the first key operation; In the 8-reel game's hash value library, each hash value corresponds to a special operation's starting move. Different 8-reel games have different hash value libraries. If the hash value library of the 8-reel game contains a hash value that matches the hash value of the first button operation, it means that the first button operation is a special operation's starting move. If the hash value library of the 8-reel game does not contain a hash value that matches the hash value of the first button operation, it means that the first button operation is not a special operation's starting move. The time required for the user to complete the special operation is matched with the preset time.
3. The method according to claim 1, characterized in that, The CPU includes a performance core processing unit, the player intent prediction engine is built into the performance core processing unit, and the performance core processing unit is directly bound to the user's operation input.
4. The method according to claim 1, characterized in that, When the user's operation of the handheld game console is an operation performed by the user for an 8-axis game running on the handheld game console, the second button operation is the complete special operation.
5. The method according to any one of claims 1-4, characterized in that, When the user's operation of the handheld game console is an operation performed by the user on a 4-axis game running on the handheld game console, the handheld game console is configured to only need to increase the frequency of the CPU; Increasing the CPU frequency includes: If the frequency of key direction changes is greater than or equal to the frequency threshold, and the number of key presses is less than the number of key presses threshold, then the player intent prediction engine sends a first instruction to the CPU, which instructs the CPU to increase its frequency to a first frequency; if the frequency of key direction changes is greater than or equal to the frequency threshold, and the number of key presses is greater than or equal to the number of key presses threshold, then the player intent prediction engine sends a second instruction to the CPU, which instructs the CPU to increase its frequency to a second frequency; if the number of key presses is greater than or equal to the number of key presses threshold, and the average key press interval duration is less than or equal to the interval duration threshold, then the player intent prediction engine sends a third instruction to the CPU, which instructs the CPU to increase its frequency to a third frequency. Wherein, the first frequency is less than the second frequency, and the second frequency is less than the third frequency.
6. The method according to any one of claims 1-4, characterized in that, The handheld game console's graphics driver layer has a built-in GPU instruction block sniffer. When the user's operation on the handheld game console is an operation performed by the user on an 8-axis game running on the handheld game console, the handheld game console is configured to increase the CPU frequency and the GPU frequency; increasing the CPU frequency and the GPU frequency includes: The player intent prediction engine sends a CPU upclocking command to the CPU, which instructs the CPU to increase its frequency from the current level to the next level; and the player intent prediction engine sends a GPU upclocking command to the GPU instruction block sniffer; the GPU instruction block sniffer controls the GPU upclocking based on the GPU upclocking command and the GPU drive commands generated by the 8-axis game running on the handheld game console.
7. The method according to claim 6, characterized in that, The GPU instruction block sniffer controls the GPU upclocking based on the GPU upclocking instructions and the GPU drive instructions generated by the 8-axis game running on the handheld gaming console, including: The GPU instruction block sniffer, based on the GPU upclocking instruction, increases the GPU's memory frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency from the current level to the next level; then... If the GPU instruction block sniffer detects that the GPU driver instruction is a texture bombing type, the GPU instruction block sniffer will continue to increase the memory frequency to the next level, and maintain the shader core frequency, the geometry processing unit frequency and the raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is a complex shader type, the GPU instruction block sniffer will continue to increase the shader core frequency to the next level, while maintaining the memory frequency, the geometry processing unit frequency, and the raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is of high vertex load type, the GPU instruction block sniffer will continue to increase the frequency of the geometry processing unit to the next level, while maintaining the memory frequency, the shader core frequency and the raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is a post-processing effect type, the GPU instruction block sniffer will continue to increase the memory frequency and the shader core frequency to the next level, while maintaining the geometry processing unit frequency and the raster unit frequency. If the GPU instruction block sniffer detects that the GPU driver instruction is a particle explosion type, the GPU instruction block sniffer will continue to increase the memory frequency and the raster unit to the next level, while maintaining the shader core frequency and the geometry processing unit frequency.
8. The method according to claim 7, characterized in that, After the GPU instruction block sniffer increases the GPU's memory frequency, shader core frequency, geometry processing unit frequency, and raster unit frequency from the current level to the next level based on the GPU upclocking instruction, the method further includes: If the player intent prediction engine determines that the user has not entered the complete special operation, the player intent prediction engine sends a downclocking instruction to the CPU and a GPU downclocking instruction to the GPU instruction block sniffer.