Intelligent energy consumption adjusting method and system for graphics card component

Abstract

The invention relates to the field of graphics card energy consumption adjustment, in particular to an intelligent energy consumption adjustment method and system for a graphics card assembly. The method comprises the following steps: acquiring running state information of a graphics card; performing game picture energy consumption calculation based on the display card running state information to obtain a display card energy consumption value mapping table; acquiring a game end operation log based on the game engine interface; performing picture content rendering difficulty calculation according to the game end operation log to obtain a real-time picture rendering difficulty value; acquiring a player operation instruction stream; performing player operation intention depth identification based on the player operation instruction stream to obtain a real-time operation intention; performing game picture demand frame rate analysis and energy consumption-frame rate energy consumption and frame rate balance adjustment according to the real-time operation intention, and constructing an energy consumption-frame rate energy consumption and frame rate balance adjustment curve; and dynamically scheduling the graphics card computing unit based on the graphics card energy consumption value mapping table and the real-time picture rendering difficulty value. The energy efficiency of the graphics card is optimized, the game experience is improved, and the energy consumption is reduced.

Description

Technical Field

[0001] This invention relates to the field of graphics card power consumption regulation, and more particularly to a method and system for intelligent power consumption regulation of graphics card components. Background Technology

[0002] The rapid development of the gaming industry and the continuous advancement of graphics technology have made graphics cards, as a crucial component of computer graphics processing, one of the core drivers of high-quality gaming experiences. The complexity of modern game scenes and the demands for image quality are constantly increasing, especially driven by emerging technologies such as high resolution, multi-dimensional graphics processing, and virtual reality (VR) and augmented reality (AR), leading to an explosive growth in graphics card performance requirements. At the same time, as gamers' demands for smoothness, image detail, and real-time responsiveness continue to rise, the computational load and power consumption of graphics cards are becoming increasingly significant.

[0003] Compared to traditional computing tasks, graphics cards in gaming scenarios not only need to handle a large number of complex operations such as graphics rendering, physics calculations, lighting effects, and dynamic textures, but also need to respond to player input commands in real time. Especially in large open-world games or massively multiplayer online games, the game visuals are constantly changing, and the demands for real-time rendering and computing are extremely high. This causes the graphics card to operate under high load for extended periods, resulting in a surge in power consumption and impacting overall system performance and the player's experience. With the continuous advancement of hardware technology, while improving performance, the computing units and power management technologies of graphics cards have also brought increasingly complex energy efficiency management challenges. The energy consumption level of high-performance graphics cards is often closely related to the complexity of the game scenes they process, the graphics rendering requirements, and player actions. Existing graphics card energy efficiency management methods are often limited to fixed power consumption control or coarse adjustments based on game type, failing to dynamically and accurately optimize energy consumption according to real-time game demands, player actions, and scene changes. Therefore, how to accurately control energy consumption based on real-time changes in game scenes, player behavior, and the graphics card's operating status has become an urgent need to improve game performance and reduce power consumption. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes an intelligent power consumption regulation method and system for graphics card components, thereby resolving at least one of the aforementioned technical problems.

[0005] To achieve the above objectives, the present invention provides an intelligent power consumption regulation method for graphics card components, comprising the following steps: Step S1: Obtain graphics card operating status information; calculate game screen power consumption based on the graphics card operating status information to obtain a graphics card power consumption value mapping table; Step S2: Collect game client operation logs based on the game engine interface; calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value; Step S3: Obtain the player's operation command stream; perform deep recognition of the player's operation intent based on the player's operation command stream to obtain the real-time operation intent; Step S4: Analyze the game screen frame rate requirements and adjust the energy consumption-frame rate balance based on the real-time operation intention, and construct the energy consumption-frame rate balance adjustment curve. Step S5: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, dynamically schedule the graphics card computing units, and combine the power consumption-frame rate power consumption and frame rate balance adjustment curve to perform dynamic control of graphics card power consumption.

[0006] This specification provides an intelligent power consumption regulation system for a graphics card component, used to execute the intelligent power consumption regulation method for the graphics card component as described above, including: The screen power consumption calculation unit is used to obtain the graphics card operating status information; and to perform game screen power consumption calculation based on the graphics card operating status information to obtain a graphics card power consumption value mapping table. The rendering difficulty calculation unit is used to collect game client operation logs based on the game client operation logs; and to calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value. The intent recognition unit is used to acquire the player's operation command stream; based on the player's operation command stream, it performs deep recognition of the player's operation intent to obtain the real-time operation intent; The frame rate balancing unit is used to analyze the frame rate required by the game screen according to the real-time operation intention and adjust the energy consumption-frame rate energy consumption and frame rate balance, and build an energy consumption-frame rate energy consumption and frame rate balance adjustment curve. The dynamic power consumption control unit is used to dynamically schedule the graphics card computing unit based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, and to perform dynamic power consumption control of the graphics card by combining the power consumption-frame rate power consumption and frame rate balance adjustment curve.

[0007] The beneficial effects of this invention are as follows: By collecting the graphics card's operating status (such as temperature, load, power consumption, etc.) in real time, the current performance and energy consumption level of the graphics card can be accurately understood, providing data support for subsequent optimization. Based on the specific operating status of the graphics card, a detailed energy consumption value mapping table is calculated. This mapping table helps to accurately predict and manage energy consumption under different operating conditions, thereby dynamically adjusting the graphics card's energy efficiency during game operation. By analyzing the game engine's operation logs, the difficulty and complexity of the rendering process in the game scene can be captured in real time. This data reflects the rendering load of the game screen and can help determine the graphics card resource requirements under different scenes. The calculation of the screen rendering difficulty value allows the system to adjust the graphics card's operation mode according to the real-time game content, ensuring that the graphics card does not work overloaded, while ensuring image quality and rendering smoothness. Deep recognition of player operation intentions can help the system understand the player's operation intentions and analyze the player's game style and behavior. This allows the system to predict the player's needs, such as certain operations that may require higher frame rates or lower latency, and these needs can directly affect the graphics card's working mode. The system can adjust the graphics card's performance in real time according to the player's operation. For example, when players perform complex actions, they may need to increase the frame rate and graphics processing power, and the system can appropriately increase the load on the graphics card. By analyzing real-time operation intentions, the system can adjust the frame rate according to the game's real-time needs, ensuring an optimal balance between smoothness and power consumption. Excessively high frame rates can lead to unnecessary power waste, while low frame rates can negatively impact the gaming experience. This adjustment curve provides a flexible and efficient way to control the balance between power consumption and gaming experience. The power consumption-frame rate balance adjustment curve can be adjusted in real-time according to different scenarios or player needs, avoiding unnecessary increases in the graphics card load and thus reducing power consumption. Combining the graphics card's power consumption value mapping table, the image rendering difficulty value, and the power consumption-frame rate balance adjustment curve, the system can dynamically schedule the graphics card's computing units during operation. For example, under light loads, the graphics card can reduce power consumption; under complex game scenes, the graphics card can allocate more resources to ensure game quality. This dynamic scheduling not only improves the graphics card's efficiency but also reduces unnecessary energy consumption. The dynamic adjustment of the graphics card ensures that the game maintains a high level of smoothness under different load conditions and reduces power waste. Players can enjoy a high-quality gaming experience while avoiding excessive power consumption. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating the steps of an intelligent power consumption regulation method for a graphics card component according to the present invention. Figure 2 This is a detailed flowchart illustrating the implementation steps of step S1. Figure 3This is a flowchart illustrating the detailed implementation steps of step S2. Detailed Implementation

[0009] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0010] This application provides a method and system for intelligent power consumption regulation of a graphics card component. The executing entity of the intelligent power consumption regulation method and system for the graphics card component includes, but is not limited to, mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc., which can be considered as general computing nodes in this application. The data processing platform includes, but is not limited to, at least one of an audio / image management system, an information management system, and a cloud data management system.

[0011] Please see Figures 1 to 3 This invention provides a method for intelligent power consumption regulation of graphics card components, comprising the following steps: Step S1: Obtain graphics card operating status information; calculate game screen power consumption based on the graphics card operating status information to obtain a graphics card power consumption value mapping table; Step S2: Collect game client operation logs based on the game engine interface; calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value; Step S3: Obtain the player's operation command stream; perform deep recognition of the player's operation intent based on the player's operation command stream to obtain the real-time operation intent; Step S4: Analyze the game screen frame rate requirements and adjust the energy consumption-frame rate balance based on the real-time operation intention, and construct the energy consumption-frame rate balance adjustment curve. Step S5: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, dynamically schedule the graphics card computing units, and combine the power consumption-frame rate power consumption and frame rate balance adjustment curve to perform dynamic control of graphics card power consumption.

[0012] In the embodiments of the present invention, see Figure 1 The diagram below illustrates the steps of an intelligent power consumption regulation method for a graphics card component according to the present invention. In this example, the steps of the intelligent power consumption regulation method for the graphics card component include: Step S1: Obtain graphics card operating status information; calculate game screen power consumption based on the graphics card operating status information to obtain a graphics card power consumption value mapping table; In this embodiment, during the game startup phase, the system first communicates with the underlying hardware through the graphics card driver interface (such as NVIDIA's NVML library or AMD's Radeon Open Compute programming framework) to collect complete operating status information of the current graphics card. The collected status parameters include: the current frequency of the GPU core (typically ranging from 300MHz to 2400MHz, which determines the working speed of the computing unit), the operating frequency of the video memory (VRAM) (ranging from 1000MHz to 16000MHz, affecting video memory bandwidth), the current power supply voltage (ranging from 0.6V to 1.2V, directly affecting dynamic power consumption), the power limit set under power management (TDP value, such as 250W, 350W, etc.), the real-time chip temperature (read by the onboard temperature sensor), fan speed and cooling status, the active status of the cache levels (L1 / L2 / L3 cache hit rate and bandwidth usage), video memory bandwidth utilization, and other operating parameters from multiple dimensions.

[0013] After data collection is complete, the system enters the energy consumption modeling stage for the game scene. At this point, the game needs to run for a period of time under different rendering scenarios (usually a 3-5 minute warm-up phase) to collect sufficient energy consumption sample data. During this period, the system will traverse various typical screen types that may appear in the game, including: menu interface scenes (UI rendering, lowest computational load), low-complexity scenes (such as indoor environments, open squares, number of triangles <500K), medium-complexity scenes (normal scenes during combat, number of triangles 500K-2M), high-complexity scenes (dense enemies, numerous particle effects, number of triangles >2M), cutscene scenes (pre-rendered or real-time CG, dense effects), and other representative scenes.

[0014] For each scene type, the system uses the following sampling method to accurately measure power consumption. Using the graphics card's built-in power counter or external power measurement hardware (such as Nvidia Power Monitor or a professional power analyzer), the system records the GPU's real-time power consumption curve for that scene type at millisecond-level sampling intervals (typically 1ms-10ms). For example, in a menu interface scene, with a sampling period of 10ms and a sampling duration of 60 seconds, 6000 power data points can be obtained. These data points are used to calculate: the average power for that scene type (the arithmetic mean of all sampling points, e.g., the average power for a menu interface is 8W), peak power (the maximum value within the sampling period, e.g., 12W), power fluctuation amplitude (the difference between the maximum and minimum values, e.g., 12W-5W=7W, indicating good stability), and power standard deviation (reflecting the severity of power changes; the smaller the value, the more stable the system).

[0015] After sampling multiple scene types, the system will establish a detailed "scene content complexity - graphics card power consumption" mapping table. For example, the specific data observed in the experiment are as follows: menu interface scenes correspond to an average power of 8W (power range 5-12W); low complexity scenes correspond to an average power of 35W (power range 30-40W); medium complexity scenes correspond to an average power of 85W (power range 75-95W); high complexity scenes correspond to an average power of 145W (power range 130-160W); and cutscenes correspond to an average power of 120W (power range 110-135W). Simultaneously, the system records the graphics card operating parameters corresponding to each complexity level, such as average GPU core frequency, memory frequency, voltage value, cache hit rate, etc., forming a multi-dimensional mapping table structure.

[0016] The establishment of this mapping table also needs to consider the nonlinear characteristics of the hardware operating points. Even with the same screen complexity, different combinations of frequency and voltage will result in different power consumption. Therefore, the mapping table should also include a parameterized energy consumption calculation model, using a polynomial model of the form "P = P_base + α×f + β×f² + γ×V²×f" to represent the relationship between power and operating parameters. Here, P_base is the base leakage power (approximately 30% of the total power consumption), f is the operating frequency, V is the operating voltage, α and β are frequency correlation coefficients, and γ is the voltage correlation coefficient. By measuring at multiple operating points, these coefficients can be fitted using the least squares method, thereby establishing a general model capable of predicting power consumption at any operating point.

[0017] Finally, the system packages and stores this mapping table along with the corresponding runtime parameter configurations to form a game-specific energy consumption configuration file. When the game runs subsequently, the system can quickly consult this table and directly map the real-time detected screen complexity to the corresponding expected energy consumption value, serving as the input benchmark for subsequent steps.

[0018] Step S2: Collect game client operation logs based on the game engine interface; calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value; In this embodiment, throughout the entire game runtime, the system continuously collects real-time runtime logs at the game engine level through interfaces and hook functions provided by the game engine. For mainstream game engines, the collection methods include: using the ProfilerRecorder API in the Unity engine to obtain rendering statistics for each frame; calling commands such as Stat RHI and Stat Unit in Unreal Engine to output rendering performance data; and collecting workload statistics for each stage of the rendering pipeline through instrumentation in custom engines. The key runtime log data collected includes: the number of draw call counts submitted to the GPU for each frame (typically 100-10000 times), the total number of visible triangles (Triangle Count, ranging from hundreds of thousands to millions), the number of rendered dynamic objects, the number of active light sources in the scene (directional lights, point lights, spotlights, etc.), the number of emitters and the total number of active particles in the particle system, texture sampling frequency, the number of pixels that passed the depth test, and other multi-dimensional rendering work indicators.

[0019] After collecting this raw data, the system performs further processing and analysis. First, the data is normalized, converting various metrics into a unified standardized space (e.g., the range of 0-1). Taking the number of triangles as an example, if the minimum number of triangles in the game is 100,000 (menu interface) and the maximum is 5 million (high-complexity battles), then the number of triangles T in any frame is normalized: T_norm = (T - 100000) / (5000000 - 100000), resulting in a standardized value between 0 and 1. All other metrics are processed similarly.

[0020] Next, a multi-dimensional score for rendering difficulty is calculated. The system uses a weighted summation method to combine multiple standardized indicators to obtain a comprehensive rendering difficulty index. The calculation formula is as follows: RenderingDifficulty = w1×(TriangleCount_norm) + w2×(DrawCallCount_norm) + w3×(LightCount_norm) + w4×(ParticleCount_norm) + w5×(TextureSampleDensity_norm) + w6×(DepthComplexity_norm) The settings for the weight coefficients w1-w6 need to be based on experience and experimental verification. Typical settings are: w1=0.25 (for the highest proportion of triangles), w2=0.20 (drawing is also important), w3=0.15, w4=0.15, w5=0.15, w6=0.10. These weights can be fine-tuned according to the specific game type. For example, in games with dense particle effects, the weight of w4 should be increased; in engines with complex lighting, the weight of w3 should be increased.

[0021] The RenderingDifficulty value calculated by this formula is a continuous value between 0 and 1. To facilitate subsequent energy consumption mapping and decision-making, the system further discretizes this continuous value into a graded difficulty level. A common grading scheme is a 5-level system: when RenderingDifficulty is 0-0.2, it is judged as "Very Light" difficulty (corresponding to menus, cutscenes, etc.); 0.2-0.4 is "Light" difficulty (low-complexity scenes); 0.4-0.6 is "Medium" difficulty (normal game scenes); 0.6-0.8 is "Heavy" difficulty (combat climax or intense scenes); and 0.8-1.0 is "Super Heavy" difficulty (extremely complex scenes).

[0022] Record the trend information of difficulty changes. Calculate the difficulty difference between adjacent frames: ΔDifficulty = Difficulty[i] - Difficulty[i-1]. If ΔDifficulty > 0.15 (significant increase in difficulty), the system will mark it as "approaching high load"; if ΔDifficulty < -0.15 (significant decrease in difficulty), it will mark it as "approaching exit from high load". This trend information will play an important role in subsequent prediction and control.

[0023] Ultimately, the real-time rendering difficulty value output by the system is a structured data containing multiple information dimensions: the difficulty level of the current frame, the smoothed difficulty value, the trend of difficulty change, and the corresponding main driving factors (such as "caused by a high number of triangles and a large number of particle effects"), which provides accurate input information for subsequent energy consumption control.

[0024] Step S3: Obtain the player's operation command stream; perform deep recognition of the player's operation intent based on the player's operation command stream to obtain the real-time operation intent; In this embodiment, the player's operation command stream is acquired in real time through the game input processing system. These operation commands include: keyboard input (WASD movement keys, spacebar jump, E interaction key, Q / R / R skill hotkeys, M to open menu, etc.), mouse input (XY axis coordinate movement, left click, right click long press), and gamepad input (joystick offset, shoulder buttons, trigger button pressure value), etc. The system records the timestamp, type, intensity, and other information of each operation command with millisecond-level precision, forming a continuous operation command stream. For example, within a 500ms time window, it may be recorded as: "T=0ms keyboard press W, T=10ms mouse X move +20 pixels, T=50ms mouse Y move -15 pixels, T=100ms keyboard press Shift, T=200ms mouse left click, T=250ms keyboard release W", etc.

[0025] Based on this command flow, the system performs feature extraction and analysis across multiple dimensions. First, the operation frequency is calculated, defined as the number of commands per unit of time. A time window (usually 1 second) is set, and the total number of commands within the window is counted. For example, if 18 independent commands appear within 1 second, the operation frequency is 18 ops / s. According to observations, the operation frequency varies significantly depending on the player's behavior: 2-5 ops / s when browsing the menu interface; 5-10 ops / s when exploring low-risk scenarios; 15-25 ops / s in medium-level combat; and 30-50 ops / s in intense combat.

[0026] Secondly, we analyze the diversity of operations, that is, the number of button types involved in the commands. If a player simultaneously performs multiple operations such as movement, camera movement, and skill activation, it indicates that they are engaging in complex interactive behavior. The diversity metric is defined as: Diversity = (Number of different button types involved) / (Total number of button types). Higher diversity indicates more complex operations, suggesting the player is performing multitasking.

[0027] The continuity and intensity of operations are analyzed again. Some operations (such as holding down a movement key) appear as continuous events in the instruction stream, while others (such as clicking a menu button) appear as instantaneous events. The system calculates the cumulative time of continuous operations and the frequency of instantaneous operations to form a continuity index. If the duration accounts for more than 60% of the total time, it is judged as a "continuous operation state"; if the instantaneous operation frequency is higher than 20 ops / s, it is judged as a "high-frequency rapid operation".

[0028] Based on the above feature extraction, the system performs deep recognition of player operation intentions. The recognition of operation intentions employs a multi-stage classification strategy. First, preliminary classification is performed based on the high-level attributes of the operation commands: If the operation is mainly menu navigation (M key, mouse click in menu area, option confirmation), it is classified as "menu operation intent"; If the operation involves a large number of movement commands and the mouse turning range is small, it is classified as "smooth exploration intent"; If skill hotkeys appear frequently during operation and are repeatedly triggered in a short period of time, it is classified as "intense combat intention"; If the frequency and diversity of operations suddenly increase, it is identified as an "emergency response intention" (such as a sudden encounter with an enemy or danger). If the operation frequency is low and it mainly involves minor directional adjustments, it is classified as "careful observation of intentions" (such as appreciating the scenery or thinking about decisions).

[0029] Further in-depth identification requires considering the temporal patterns of the operation sequence. For example, the system can calculate the autocorrelation of operation commands to observe whether there are periodic operation patterns (such as fixed-cycle skill release). If the autocorrelation coefficient is greater than 0.7, it indicates that the player is performing regular repetitive operations (such as combos or repeated spellcasting), which can be identified as "skill cycle combat intention". At the same time, the start and stop events of operations should also be analyzed, that is, the rapid rise and fall of operation intensity. If the operation frequency surges from 5 ops / s to 40 ops / s within 500ms, it is marked as a "combat start event"; if it drops rapidly from 40 ops / s to 5 ops / s, it is marked as a "combat end event".

[0030] Finally, the system needs to correlate and verify the identified operational intent with the game state. For example, if high-frequency operations and skill hotkeys are detected in the menu interface, the system should not incorrectly determine it as "intense combat intent," but rather interpret it as "the player is quickly browsing the menu." This contextual verification can improve the accuracy of intent recognition.

[0031] The final output of the recognition result is a real-time operation intent label, including intent type, confidence score (between 0 and 1, indicating the credibility of the judgment), and trend information (such as "intent is shifting from exploration to combat"). The system records the intent recognition results of the past 5 frames to form an intent change sequence, which is used to predict the intent trajectory in the next few frames.

[0032] Step S4: Analyze the game screen frame rate requirements and adjust the energy consumption-frame rate balance based on the real-time operation intention, and construct the energy consumption-frame rate balance adjustment curve. In this embodiment, when a menu operation intent is recognized, the user's sensitivity to frame rate is low because the menu interface is static or has low dynamic content. The target frame rate can then be set to the range of 30fps-40fps. In this mode, users primarily focus on the timeliness of the operation response (typically, the perceived latency threshold is 200ms) rather than the smoothness of the visuals. If the actual frame rate is below 30fps, menu scrolling or transition animations will appear sluggish; if it is above 40fps, the improvement exceeds the user's perceived range.

[0033] When the game is identified as an intention to observe carefully, the player is appreciating the game scene or contemplating a decision, resulting in infrequent and slow-moving actions. A lower frame rate is acceptable at this point, with a target frame rate of 40-50 fps. Since the player does not require rapid reactions, a slightly higher input latency (e.g., 50ms) is acceptable.

[0034] When the game detects a gentle exploration intent, players move through the game world at a relatively leisurely pace, requiring a moderate frame rate. The target frame rate is set at 50fps-60fps. At this point, both visual smoothness and responsiveness should remain at a good level to maintain a comfortable gaming experience.

[0035] High-pressure game scenarios, such as those involving intense combat or emergency responses, demand the highest frame rate. In these situations, the target frame rate should be set between 60fps and 120fps (depending on the game type and the display's refresh rate). Players are particularly sensitive to differences in frame rate in FPS games. Research shows that the improvement from 60fps to 120fps is noticeable, and even increasing to 144fps still provides a perceived further improvement. This is because combat demands fast and precise aiming and reaction time; every additional frame of smoothness reduces lag and enhances a competitive advantage.

[0036] When the game is identified as a skill-cycle combat intention, the player is performing complex multi-key combination operations, at which point the frame rate requirement is also very high, with a target of 60fps-100fps.

[0037] After establishing the intent-frame-rate mapping table, the system calculates the appropriate frame rate to be maintained in real time. This calculation is based not only on the current intent but also on the trend of intent changes. If the intent is shifting from low to high intensity (e.g., from observation to combat), the system should increase the target frame rate in advance, allowing time for the hardware to reach the new operating point and avoiding "frame rate lag" issues. The prediction method used is to calculate the rate of intent change; if the rate exceeds a threshold, the target frame rate is adjusted 1-2 frames in advance.

[0038] Next, the system obtains the graphics card's real-time rendering frame rate. By continuously recording the rendering completion timestamp of each frame, it calculates the time difference (FrameTime) between two adjacent frames, and then calculates its reciprocal to obtain the real-time FPS value: ActualFPS = 1 / FrameTime. The system typically uses a moving average method to smooth the real-time FPS to avoid fluctuations in single-frame data. The calculation formula is: SmoothFPS[i] = 0.3 × ActualFPS[i]+ 0.7 × SmoothFPS[i-1] Calculate the difference between the adaptive frame rate and the actual frame rate: ΔFrameRate = TargetFPS - ActualFPS. A positive value indicates that the current frame rate is insufficient, requiring increased computing resources; a negative value indicates that the frame rate is too high, and the energy budget can be reduced. For example, if the target is 60fps but the actual frame rate is only 45fps, then ΔFrameRate = 15fps, indicating a positive difference, and the system needs to increase energy consumption to increase the frame rate.

[0039] This analysis focuses on frame rate demand latency based on frame rate differences. Since the power adjustment of the graphics card (changes in frequency and voltage) takes some time to affect the frame rate, there is a response latency (typically 1-3 frames, or 16.7ms-50ms). The system needs to calculate the adjustment latency and the actual required power consumption adjustment. The method used is to establish a predictive model of frame rate changes and power consumption adjustments. According to experiments, increasing the graphics card power budget by 5% typically increases the frame rate by 3-5% (the specific percentage depends on the current operating point and screen complexity). Therefore, the system can establish the following predictive relationship: PredictedFPS_increase = FrameRateGain_coefficient × PowerBudget_increase_percentage FrameRateGain_coefficient is an empirical coefficient, typically ranging from 0.5 to 1.0. If a 15fps increase is needed while the current frame rate is 60fps, this represents a 25% increase in frame rate. The required increase in power budget would be: PowerBudgetIncrease = 25% / 0.75 ≈ 33%. However, such a significant increase could lead to power overruns, necessitating power budget constraints and tiered processing.

[0040] The system defines several trigger thresholds for power consumption adjustments. If ΔFrameRate > 5fps and remains at that level for more than 3 consecutive frames, a "slight power consumption increase" operation is triggered, increasing the power budget by 5-8%. If ΔFrameRate > 15fps and remains at that level for 2 consecutive frames, a "moderate power consumption increase" operation is triggered, increasing the power budget by 10-15%. If ΔFrameRate > 30fps or fails to reach the target level, a "high power consumption increase" operation is triggered, increasing the power budget by 20-30%. Conversely, if ΔFrameRate < -10fps and remains at that level for 3 consecutive frames, a "gradual power consumption decrease" operation is triggered, reducing the power budget by 5-10%.

[0041] Based on this, the system constructs an energy consumption-frame rate balance adjustment curve. This curve describes the energy budget that the graphics card should allocate to achieve the target frame rate under different operational intent modes. The curve design uses an S-shaped function to avoid system oscillation caused by a steep slope. The specific shape of the curve is as follows: When the frame rate is close to the target value (ΔFrameRate is within ±2fps), the power consumption adjustment is minimal (±0-2%), maintaining relative stability. When the frame rate deviates from the target value by 5-10fps, the power consumption adjustment increases linearly, with a slope of 1% per fps; When the frame rate deviates from the target value by more than 15fps, the power consumption adjustment enters the saturation zone, and can be adjusted up to ±30%; The curve has appropriate differential smoothness at the zero-crossing point (ΔFrameRate = 0), avoiding frequent oscillations near the target value.

[0042] The system establishes separate power consumption-frame rate power consumption and frame rate adjustment curves for different operation intention modes. In menu mode, the curve is relatively flat (with a large tolerance for frame rate fluctuations), with a maximum adjustment range of ±15%; in exploration mode, the tolerance is medium, with a maximum adjustment range of ±20%; and in combat mode, the curve is the steepest, with the strictest control over the frame rate, and a maximum adjustment range of ±35%. These different curves are stored in the system configuration, and the system smoothly transitions to the corresponding adjustment curve when the operation intention changes.

[0043] Step S5: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, dynamically schedule the graphics card computing units, and combine the power consumption-frame rate power consumption and frame rate balance adjustment curve to perform dynamic control of graphics card power consumption.

[0044] In this embodiment, the output information from the first four steps is first used to calculate the real-time energy consumption requirement. The system reads the graphics card energy consumption value mapping table (from S1) and maps the current image complexity level to the basic energy consumption requirement under that image type. For example, if step S2 calculates that the current image rendering difficulty level is "heavy" (difficulty value 0.68), the system looks up the corresponding basic energy consumption of 140W in the mapping table. Then, the system obtains the energy consumption-frame rate energy consumption and frame rate adjustment curve constructed in step S4, inputs the current frame rate difference (ΔFrameRate) into the curve function, and obtains the corresponding energy consumption adjustment ratio. If ΔFrameRate is +8fps, the energy consumption adjustment range is calculated to be +10% according to the adjustment curve, then the actual required energy consumption value = 140W × (1 + 10%) = 154W.

[0045] Based on this actual rendering power consumption requirement, the system performs dynamic scheduling and evaluation of the graphics card's computing units. The graphics card's computing units include several categories: SM clusters (streaming multiprocessors, performing vertex and pixel shading), texture units (responsible for texture sampling and filtering), caching systems (L1 / L2 cache), memory controllers (responsible for memory access), rasterization units, depth testing units, etc. The power consumption of these units is uneven, and their load characteristics vary significantly. The system needs to analyze the load of each unit under the current rendering difficulty to determine which units should have their frequency adjusted.

[0046] The system employs an analysis method based on monitoring hardware performance counters. Tools such as NVIDIA's Nsight or AMD's GPU Profiler can be used to obtain utilization information for each computing unit. For example, this includes: SM cluster utilization (typically 0-100%, indicating the percentage of shader cores actively computing), texture unit utilization (indicating the number of texture sampling requests queued), memory bus utilization (indicating the percentage of memory bandwidth used), and cache hit rate (indicating the percentage of memory accesses that can be directly retrieved from the cache).

[0047] Based on this utilization data, the system establishes a priority model for workload bottlenecks. If the SM cluster utilization is the highest (e.g., 95%), it indicates that computationally intensive tasks are the current bottleneck, and this should be improved by increasing the GPU core frequency. If the texture unit utilization is the highest (e.g., 90%), it indicates that texture sampling is the bottleneck, and this can be improved by optimizing texture access or increasing the texture unit frequency. If the memory utilization is the highest (e.g., 85%), it indicates that bandwidth is the bottleneck, and the memory frequency should be increased. By analyzing this bottleneck information, the system determines the frequency domain that should be adjusted.

[0048] Next, the system dynamically adjusts the frequency and voltage. Modern graphics cards support DVFS (Dynamic Voltage and Frequency Scaling) technology, which allows the GPU core frequency and power supply voltage to be changed at runtime. The system issues new frequency and voltage commands through the graphics card driver interface. The goal of the adjustment is to achieve the "actual rendering power consumption value" (such as 154W in the previous example).

[0049] The specific adjustment process follows this logic: First, obtain the current GPU core frequency and voltage (e.g., currently 1200MHz, 0.95V). Using the power prediction model "P = P_base + α×f + β×f² + γ×V²×f" established in step S1, calculate the expected power consumption under different frequency and voltage combinations. Assuming a change to 1250MHz and 0.98V, substituting this into the model yields an expected power consumption of 158W, close to the target value of 154W; if changed to 1230MHz and 0.96V, the expected power consumption is 155W, very close to the target. The system will choose the latter as the new operating point because, while achieving the energy consumption target, a lower frequency and lower voltage can reduce heat generation and improve system stability.

[0050] The system uses a similar method to adjust the memory frequency and voltage. The necessary memory frequency is calculated based on memory utilization and bandwidth requirements. For example, if the current memory frequency is 1000MHz but the memory bus utilization is only 40%, the system can reduce the memory frequency to 600MHz to save power consumption on the memory side (memory power consumption accounts for approximately 20-30% of total power consumption).

[0051] The system also allocates resources in stages based on the complexity of the visuals. In high-complexity scenes (such as intense battles), the system prioritizes the computational resources of SM clusters and texture units to ensure the full execution of pixel shading, as this directly affects visual quality. In low-complexity scenes (such as menu interfaces), the system can perform power gating on certain computational units, putting them into a low-power state or shutting them down completely. For example, in a menu interface, most texture units can be disabled because menus typically use pre-rendered UI images rather than complex texture samples.

[0052] In addition, the system will automatically switch between different graphics card rendering modes. The system defines three main rendering modes: High-Performance Mode: Suitable for intense combat or high-difficulty rendering scenarios. In this mode, all GPU cores maintain their highest frequency (e.g., 2400MHz), memory frequency also maintains its highest frequency (e.g., 16000MHz), and voltage is set to standard values ​​(0.95V-1.1V). The goal is to maximize frame rate, regardless of power consumption constraints. The power budget is typically set to 150W or higher. This mode is switched on when: the real-time operation intent is "intense combat" or "emergency response," the frame rate is more than 30% below the target, or the player explicitly selects the "performance priority" setting.

[0053] Balanced Mode: Suitable for normal gaming scenarios. The GPU core frequency is maintained at a moderate level (e.g., 1600-1800MHz), the memory frequency is moderately reduced (e.g., 8000MHz), and the voltage is reduced by approximately 5% (e.g., 0.92V). The power consumption budget is typically 80-120W. This mode attempts to achieve a balance between performance and power consumption and is a commonly used mode in most gaming scenarios. Switching conditions are: the intended action is "gentle exploration" or "observation," and the frame rate is within ±5fps of the target value.

[0054] Power Saving Mode: Suitable for menu interfaces, transition animations, or scenarios with low frame rate sensitivity. GPU core frequency is reduced to a lower level (e.g., 800-1000MHz), memory frequency is significantly reduced (e.g., 2000MHz), and voltage is drastically reduced (e.g., 0.7V-0.8V). Some computing units enter a low-power state. The power consumption budget is 20-50W. The goal of this mode is to minimize power consumption and heat, with relatively little impact on the user experience. Switching conditions are: the operation intent is "menu operation" or "observation," the rendering difficulty is "ultra-light" or "light," and the actual frame rate is significantly higher than the target.

[0055] The system employs a smooth transition strategy when switching between these three modes. When switching from balanced mode to high-performance mode, the system does not jump immediately, but gradually increases the frequency and voltage over 2-3 frames. For example, the frequency is increased by 10% in the first frame, 15% in the second, and then fully switches to the target operating point in the third frame. This avoids power spikes and system instability caused by drastic frequency fluctuations.

[0056] The system also implements a linkage mechanism with the power consumption-frame rate balance adjustment curve. After performing frequency and voltage adjustments, the system will measure the actual frame rate in the next frame and compare the achieved frame rate with the target. If the frame rate deviates from the target by more than ±3fps, a fine adjustment will be made. For example, if the frame rate increases from 60fps to 70fps after adjustment (exceeding the target by 5fps), the system will appropriately reduce the GPU frequency to stabilize the frame rate near the target value. This forms a feedback control loop, enabling the system to continuously optimize power consumption allocation in dynamic game environments.

[0057] Finally, the system records the results of each adjustment, including power consumption, frame rate, temperature, and other metrics before and after the adjustment, forming a long-term optimization history database. This data will be used to train and improve energy consumption prediction models and control strategies, allowing the system to continuously learn and improve over long-term use, ultimately forming the optimal energy consumption control scheme for the game. The entire control process is fully automated and transparent; users do not need any manual configuration or intervention to obtain the optimal operating effect that ensures a smooth gaming experience while effectively saving power.

[0058] In this embodiment, see Figure 2 The diagram below illustrates the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: The system detects when the computer enters the game and obtains the graphics card's operating status information through the graphics card driver interface. Calculate the real-time power consumption data of each GPU component based on the graphics card operating status information; Identify multi-frame rendered scenes of a game; calculate the peak power, energy integral, and power fluctuation rate of the multi-frame rendered scenes of the game, calculate the density index, and obtain the graphics card energy consumption value of a single frame. The game's multi-frame rendered footage is categorized by frame type to obtain frame type labels; the frame type labels include battle scenes, cutscenes, and menu interfaces. Based on the image type label, the graphics card power consumption value of a single frame is associated and matched to obtain a graphics card power consumption value mapping table for multiple image types.

[0059] In this embodiment, to ensure the computer enters game mode, the process management tools provided by the operating system can be used to monitor the startup of specific game processes. For example, in Windows systems, Task Manager can be used to check if the game process has started, or a script can be used to detect if the game is running in the background. After entering the game, the next step is to obtain relevant hardware information from the graphics card driver. Taking NVIDIA graphics cards as an example, the NVAPI interface can be used to obtain the GPU's operating status, including GPU load (e.g., percentage), core frequency, memory usage, temperature, and real-time power consumption. Typically, when the GPU load is close to 100%, power consumption is high, while memory usage exceeding 90% can lead to a significant increase in graphics card power consumption. In addition, GPU temperature can also be obtained (e.g., 70°C or higher may indicate increased power consumption). These parameters will serve as the basis for subsequent power consumption analysis. After obtaining the overall status information of the graphics card, the next step is to break down the power consumption of each GPU component in detail. For example, the GPU core frequency of a graphics card typically varies between 1000 MHz and 2000 MHz, while the memory frequency may fluctuate between 1500 MHz and 8000 MHz. These frequency variations directly impact power consumption. Through the graphics card driver interface, we can obtain the core and memory frequencies of each component. When the graphics card is under heavy load, such as when running graphics-intensive games, the core frequency may reach its maximum value of 1.8 GHz or higher, and the memory bandwidth will also increase with the memory's operating frequency, both leading to increased power consumption. Furthermore, the power consumption of a graphics card is also closely related to the GPU voltage and current. Assuming the GPU voltage varies between 1.0V and 1.2V, increasing the core and memory frequencies will lead to increased current demand, thus increasing power consumption. Therefore, by reading the GPU core voltage (e.g., 1.05V) and load data, the power consumption of the GPU core can be estimated. The power consumption of the memory is estimated based on its frequency (e.g., 1600 MHz) and bandwidth (e.g., 256GB / s).

[0060] The rendering load varies from frame to frame, and the graphics card's power consumption fluctuates with the complexity of the scene content. For example, in FPS games, rapidly changing scenes and complex textures can cause power consumption to fluctuate between 200W and 300W, while in a static menu interface, power consumption may drop below 50W. By collecting power consumption data for each frame (e.g., 10 samples per second), it's possible to identify which frames have higher peak power. For instance, during an intense battle, GPU power consumption might jump from 250W to 350W, creating a noticeable fluctuation. Energy integral is the total energy consumption calculated by weighting the power consumption of each frame. For example, if a frame consumes 250W and has a rendering time of 16ms (at 60 FPS), then that frame contributes 4 J of energy. Power fluctuation rate can be calculated by measuring the range of power consumption changes over a period of time. For example, certain scenes in a game might cause the graphics card's power consumption fluctuation rate to exceed 10%, indicating unstable power consumption. In games, different types of scenes have different impacts on the graphics card's load and power consumption. For example, battle scenes typically involve numerous dynamic effects, complex lighting, and particle effects, resulting in high GPU load and power consumption potentially reaching 300W or higher. Cutscenes, on the other hand, are often pre-rendered, with relatively low load and power consumption generally between 150W and 200W. Menu interfaces, however, have the simplest graphical requirements, typically consuming between 50W and 100W. For accurate classification, the scene type can be determined by analyzing the image complexity of each frame, such as the number of dynamic objects, texture details, and shadow effects. For instance, if a scene features numerous dynamic enemies and lighting effects, it can be inferred to be a battle scene. By analyzing the complexity of each frame using image processing techniques, combined with in-game event data (such as enemy numbers, scene transitions, etc.), each frame can be categorized into a specific type, such as "battle scene," "cutscene," or "menu interface."

[0061] After classifying the scene types, the next step is to correlate the single-frame GPU power consumption values ​​for different scene types and generate a mapping table. For example, in a battle scene, the power consumption per frame might fluctuate between 250W and 350W, while in a cutscene, the power consumption per frame might remain between 150W and 200W. By labeling each frame and calculating the average power consumption for each scene type, a power consumption mapping table can be obtained. For example, the average power consumption for a battle scene is 300W, the average power consumption for a cutscene is 180W, and the average power consumption for a menu interface is 80W. This mapping table can help developers adopt different energy efficiency strategies for different scenes when optimizing the game. If the power consumption of a battle scene is too high, it may be necessary to optimize the rendering algorithm or reduce the complexity of certain effects, while for the menu interface, more graphics effects can be added without worrying about a significant increase in power consumption.

[0062] In this embodiment, see Figure 3 The diagram below illustrates the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: Collect game client runtime logs based on game engine interface; Game scene elements are decomposed and identified based on the game client's operation logs, and scene element indicators are extracted; the scene element indicators include the number of visible triangles, the number of dynamic objects, the number of light sources, and the number of active particle emitters. Visual rendering features are obtained by calculating image gradient complexity, color information entropy, proportion of high-frequency texture components, and transparency channel based on scene element indicators. The difficulty of real-time image rendering is calculated based on visual rendering features to obtain the real-time image rendering difficulty value.

[0063] In this embodiment, game engines (such as Unreal Engine and Unity) typically provide logging interfaces or systems to record game runtime information, including key data such as scene changes, object interactions, and lighting calculations. To obtain this data, developers can use the engine's built-in logging system (e.g., Debug.Log in Unity or UE_LOG in Unreal Engine). By integrating specific log collection modules, real-time data can be continuously recorded during game execution, including the rendering status of each frame, game events (such as scene transitions, object creation or destruction), and performance parameters (such as frame rate and rendering time). These runtime logs involve specific game scene information, including the number of objects and changes in light sources within the scene. Regularly collecting and storing this data (e.g., every 10ms or 30ms) provides crucial information for subsequent scene element decomposition and energy efficiency analysis. By analyzing the runtime logs provided by the game engine, elements in the game scene can be decomposed, identifying key element indicators for each scene. These element indicators include: the number of visible triangles, the number of dynamic objects, the number of light sources, and the number of active particle emitters. The number of triangles is a crucial indicator of scene geometric complexity, directly impacting the graphics rendering load on the GPU. The number of dynamic objects indicates the number of real-time interactive objects in the scene; these objects may trigger dynamic updates from the GPU, such as character animations and enemy movements. The number of light sources affects scene lighting calculations; multiple light sources increase the computational burden, especially when dynamic lighting or shadow effects are used. The number of active particle emitters is related to particle effects in the scene (such as explosions, smoke, and flames); the quantity and complexity of particle effects are also important factors determining the GPU load.

[0064] To obtain this data, game engines provide direct API interfaces. For example, the Unity engine can access various elements in the scene through the Scene and GameObject classes, and NVIDIA's NSight tool can provide real-time graphics-related performance data. By parsing game logs, developers can track changes in these metrics in real time and use this to estimate the complexity of the current scene. Based on the scene element metrics extracted in the previous step, the next step is to calculate the visual rendering features of the image. These features help quantify the rendering difficulty of the image. Image gradient complexity refers to the degree of spatial variation of an image, usually used to measure the complexity of edges in an image. Images with high gradient complexity usually contain more details and edge information, placing a heavier burden on the graphics card when rendering such images. Color information entropy is used to measure the complexity of colors in an image. A high entropy value means that the color variations in the image are rich and unpredictable, requiring the graphics card to process more color information during rendering. The proportion of high-frequency texture components reflects the richness of detailed textures in the image. The higher the frequency, the richer the details in the image, and the more computing power the graphics card needs to process the texture. The complexity of the alpha channel is related to the rendering of semi-transparent objects. Scenes with high transparency typically require the graphics card to handle more lighting and shadow calculations, increasing the computational burden. These rendering features can be calculated using image processing algorithms. For example, gradient complexity can be measured by calculating the image's gradient (such as the Sobel operator), color entropy can be calculated using entropy algorithms (such as Shannon entropy), and the high-frequency components of textures can be estimated through Fourier transforms or by directly analyzing the high-frequency regions of the texture. The processing of the alpha channel can be evaluated by analyzing the alpha value of each pixel.

[0065] After calculating the visual rendering features, the next step is to synthesize this information to evaluate the rendering difficulty of each frame. This process involves assigning different weights to various visual features (such as image gradient complexity, color entropy, high-frequency texture components, and alpha channels), and then combining these feature values ​​to calculate an overall rendering difficulty value. A higher rendering difficulty value means a heavier graphics processing burden on the current scene, and a corresponding increase in the graphics card's power consumption and performance requirements. For example, in a scene with a large amount of detail and complex textures, the image gradient complexity and the proportion of high-frequency texture components may be high, resulting in a higher rendering difficulty and requiring the graphics card to consume more power for computation. Conversely, in scenes with low color entropy and simple textures, the rendering difficulty is lower, and the graphics card load and power consumption are also lower.

[0066] In this embodiment, step S3 includes the following steps: Obtain the player's operation command stream; calculate the operation frequency based on the player's operation command stream to obtain the timing operation frequency; Calculate the periodic frequency distribution and operation intensity based on the timing operation frequency; Based on the periodic frequency distribution and operation intensity, instruction continuity is identified to obtain the continuous characteristics of operation instructions; Based on the continuous characteristics of operation instructions, the player's operation intention is deeply identified to obtain the real-time operation intention; the real-time operation intention includes combat mode, static mode, casual mode, and game interface control mode.

[0067] In this embodiment, during gameplay, players perform various operations using input devices (such as mice, keyboards, touchpads, etc.). The system needs to capture these operation commands in real time for subsequent analysis. The goal of acquiring the player's operation command stream is to accurately record each player's actions. Specifically, operation commands include operation type (such as attack, movement, skill release, interface operation), operation content (such as skill selection, target selection, view adjustment), and timestamp (the precise time when the operation occurred, usually accurate to milliseconds). For example, in a certain combat scenario, a player may frequently click on attack skills; the timestamp of the operation command can accurately reflect the sequence of these frequent operations. To ensure the real-time and completeness of data collection, the experiment was set to record player operation events once per second, or to update the operation stream in real time using event capture technology. In addition, the collected operation types include, but are not limited to, player skill release, attack, movement commands, item interaction, etc. Each operation has different resource requirements and GPU load; therefore, capturing the operation command stream provides crucial data support for subsequent energy consumption optimization. After acquiring the player's operation command stream, the system needs to calculate the operation frequency. Operation frequency is a key indicator reflecting player activity and is crucial for game performance optimization. Operation frequency calculation is based on time windows to analyze player behavior across different time periods. For example, the number of actions performed by the player per second is counted, and the operation frequency is calculated using the following formula: Operation Frequency = Number of Actions / Time Window Length; the time window length is set to 1 second, so the number of actions per second is the operation frequency for that time window. To avoid the impact of frequency fluctuations on the analysis results, a moving average method (e.g., a 5-second moving average) is used to smooth the frequency data in the experiment. This helps reduce noise caused by instantaneous changes in operations, making the operation frequency curve smoother and facilitating subsequent analysis. For example, in combat mode, the player's operation frequency may increase significantly (reaching more than 2 times / second), while in casual mode, the frequency may remain at 1 time / second or lower. This operation frequency data provides a direct basis for subsequent energy consumption optimization; by accurately identifying the intensity of player operations, the system can dynamically adjust the graphics card load.

[0068] After calculating the timing operation frequency, the system further analyzes the periodic frequency distribution and operation intensity to help identify the player's operation patterns. Periodic analysis helps identify the regularity of player operations. For example, in high-intensity combat mode, a player's operations may repeat at a fixed cycle (e.g., executing a skill release every 2 seconds), while in casual mode, the operation cycle is longer and irregular. Therefore, the system uses Fourier transform to perform frequency domain analysis on the operation frequency data to extract periodic features. Fourier transform can convert timing data into frequency domain data, revealing the periodicity of frequency fluctuations. For example, through Fourier transform, it may be found that players frequently use 2Hz and 4Hz operation cycles in combat mode, while in casual mode, the frequency distribution is more dispersed and the cycle is longer.

[0069] In calculating operational intensity, the system comprehensively evaluates both operation frequency and complexity. For example, if a player's operation frequency is high and each operation involves complex skill combinations (such as pressing multiple keys simultaneously), the operational intensity is high; conversely, if the operation frequency is low and the content is simple (such as clicking the left mouse button for a basic attack), the operational intensity is low. Operational intensity can be calculated using the following formula: Operational Intensity = Operational Frequency × Operational Complexity; where operational complexity is scored based on the type and complexity of the operation, with complex operations (such as multi-skill combos or rapid reactions in combat) typically having higher complexity. In the experiment, scoring criteria for operational complexity were set, such as a score of 1 for a single key press, a score of 2 for a combination of skills, and a score of 3 for multiple skill linkages. Through this method, the system can accurately assess the player's operational intensity within each time window, thereby identifying the player's game mode.

[0070] Based on the periodic frequency distribution and operational intensity, the system further identifies command continuity. The continuity of operational commands reflects the stability and consistency of player behavior. For example, in combat mode, players may execute skill release or attack commands consecutively, while in casual mode, operations are often spaced further apart, exhibiting lower continuity. To identify this characteristic, the system employs the Dynamic Time Warping (DTW) method to compare the similarity of operational frequency sequences across different time windows. DTW is an algorithm that measures the similarity of time-series data, aligning operational commands along the timeline to identify continuity and variation in operational patterns.

[0071] Through DTW (Time-Based Visualization), the system can identify continuous operation patterns in combat mode (such as frequent skill releases) and intermittent operations in casual mode (such as occasional camera adjustments or item usage). In the experiment, a similarity threshold was set. When the temporal similarity between two sets of operation commands exceeded this threshold, the system determined that the player was in a high-continuity operation range (such as combat mode). Conversely, when the similarity of the operation commands was low, the system identified it as a low-continuity pattern (such as casual or static mode). This continuity recognition provides crucial support for deep recognition of operation intentions.

[0072] Based on the continuity of player commands, the system can deeply identify the player's operational intentions. The goal of intention recognition is to determine the player's current game state, providing a basis for optimizing graphics card power consumption. Specifically, player operational intentions include the following patterns: Combat mode: High-frequency and continuous high-intensity operations, usually involving skill release, attack, etc.

[0073] Quiet mode: Low-frequency operation, players are usually in standby mode and perform few operations.

[0074] Casual Mode: Players engage in less frequent actions, such as exploration, chatting, or other non-combat activities.

[0075] Game interface control mode: Frequent interface operations, players mainly perform settings, view inventory or menus.

[0076] To identify players' operational intentions, the system uses machine learning algorithms (such as Support Vector Machines (SVM) or Deep Neural Networks (DNN)) to train features such as operation frequency, intensity, and continuity. In experiments, through learning from a large amount of player behavior data, the model can output the player's current operational intention based on real-time operation features. For example, in combat mode, where the player's operation frequency and complexity are high, the system automatically increases the GPU load to improve graphics rendering capabilities; while in static or casual modes, the system reduces the GPU load to save energy.

[0077] In this embodiment, step S4 includes the following steps: The game screen frame rate range required by the real-time operation intention is calculated to obtain the theoretically adapted screen frame rate. Calculate the real-time frame rate of the game screen; Define a short-term calculation period, and calculate the periodic average of the real-time frame rate of the game screen according to the short-term calculation period to obtain the actual game frame rate; The frame rate difference is calculated by performing a frame rate difference calculation on the actual game frame rate based on the theoretically adapted frame rate; Timing tracking statistics are performed based on the frame rate difference to obtain the frame rate difference distribution curve; Based on the frame rate difference distribution curve, future frame adaptation compensation calculation and energy consumption-frame rate balance adjustment are performed to construct the energy consumption-frame rate balance adjustment curve.

[0078] In this embodiment, in the game scene, the player's real-time operational intentions (such as combat mode, casual mode, static mode, etc.) directly affect the rendering requirements of the game screen. First, the system needs to infer the required frame rate range of the game screen based on the player's real-time operational intentions. This process is based on the analysis of the player's operation frequency and intensity, as well as the rendering load requirements of the graphics card. For example, in combat mode, players frequently perform high-frequency operations (such as skill release, attack, etc.), which require the game screen to be rendered at a high frame rate to ensure the smoothness of the screen; while in casual mode, the player's operation frequency is lower, and the rendering requirements of the game screen are correspondingly reduced. The system first calculates the theoretically suitable frame rate range through the player's real-time operation characteristics, such as operation frequency (how many operations per second) and operation intensity (operation complexity). By evaluating the operation intensity, the system can roughly determine the minimum and maximum frame rates required by the game screen in different game modes. For example, the system may define the theoretical frame rate range in combat mode as 60-120 FPS, while in static mode, the frame rate range is 30-60 FPS. This depends on the operation frequency threshold and operation complexity scoring criteria in the experiment. The operation frequency can be set to the number of operations per second, while the operation complexity is scored based on the type of operation and the diversity of player input. The system will dynamically adjust the theoretical frame rate range of the screen rendering based on these parameters to ensure that the graphics card can perform graphics rendering at an appropriate frame rate without affecting the player experience.

[0079] Real-time frame rate is a key parameter reflecting the current rendering efficiency of a game, typically calculated by the game engine each frame. The game engine dynamically calculates the actual frame rate per second based on factors such as hardware performance (e.g., GPU load), scene complexity, and current rendering demands. The formula for calculating the frame rate is: Real-time frame rate = 1 / Rendering time per frame; where rendering time per frame refers to the time taken by the GPU to complete one rendering task, usually measured in milliseconds. In the experiment, the real-time frame rate was calculated by monitoring the rendering duration of each frame, and this rendering time dynamically changes based on scene complexity and player actions. For example, in high-load combat mode, the game scene rendering may be more complex, requiring more computing resources, thus increasing the rendering time per frame and correspondingly decreasing the real-time frame rate. In static or casual modes, scene rendering is simpler, resulting in a higher frame rate.

[0080] To effectively evaluate the actual frame rate of the game and avoid the impact of instantaneous fluctuations on the analysis results, the system introduces a short-term calculation period. The short-term calculation period refers to smoothing the real-time frame rate within a set time window to obtain a more stable frame rate value. Common short-term calculation periods are 5 seconds, 10 seconds, or 20 seconds, with the specific period length determined based on experimental requirements and real-time frame rate fluctuations. Within each calculation period, the system averages all frame rate data within that period to obtain the actual game frame rate. This processing method effectively eliminates instantaneous frame rate fluctuations caused by factors such as game load fluctuations and changes in scene complexity, resulting in smoother frame rate data that facilitates subsequent analysis.

[0081] For example, after setting a short calculation period of 10 seconds, the system will average all real-time frame rate data within those 10 seconds to obtain the actual game frame rate for that period. In combat mode, the system might find that the real-time frame rate fluctuates between 50 and 120 FPS. Through averaging over a short calculation period, the actual frame rate may be stabilized at 80 FPS. This average frame rate can more accurately reflect the actual rendering requirements of the game.

[0082] Frame rate difference calculation assesses the degree of frame rate deviation by comparing the theoretically adapted frame rate with the actual in-game frame rate. Specifically, the system first calculates the expected range of the theoretically adapted frame rate (based on player input), and then compares this range with the actual in-game frame rate. By calculating the frame rate difference between the two, the frame rate deviation at each moment can be obtained. For example, if the theoretically adapted frame rate range is 60-120 FPS, while the actual in-game frame rate is 100 FPS, the frame rate difference is 0 (indicating no deviation); if the actual in-game frame rate is 140 FPS, the frame rate difference is 20 FPS (indicating exceeding the theoretically adapted range); if the actual in-game frame rate is 50 FPS, the frame rate difference is -10 FPS (indicating below the theoretically adapted range).

[0083] The formula for calculating the frame rate difference is: Frame rate difference = Actual game frame rate Theoretically adapted to the frame rate of the video.

[0084] The time-series tracking and statistics of frame rate differences aim to identify the relationship between graphics card performance fluctuations and game operation requirements. The system analyzes frame rate differences across multiple time windows to construct a frame rate difference distribution curve, thus understanding the regularity of graphics card performance fluctuations. For example, in certain high-load combat scenarios, the system may detect significant fluctuations in frame rate differences, indicating large fluctuations in graphics card load. In casual mode, the frame rate difference may be relatively stable, indicating lower graphics card load. The frame rate difference distribution curve can be displayed using a cumulative distribution function (CDF) or a histogram. In experiments, the frame rate difference distribution curve helps the system identify sensitive areas of the graphics card, i.e., in which frame rate ranges the graphics card is prone to performance fluctuations, thus providing a reference for subsequent power consumption adjustments.

[0085] Based on the frame rate difference distribution curve, the system can perform future frame adaptation compensation calculations, that is, predict the frame rate demand at a certain point in the future and adjust the graphics card load and power consumption according to the current frame rate difference. By analyzing the distribution trend of the frame rate difference, the system can infer the rendering demand of future frames and make dynamic adjustments. For example, if the current frame rate difference is large, and similar differences may continue to occur in the next few frames, the system will reduce the graphics card load in advance to avoid excessive energy consumption.

[0086] Based on this calculation, the system can construct an energy consumption-frame rate balance adjustment curve, which reflects the energy consumption and performance balance point of the graphics card under different frame rate requirements. In the experiment, the energy consumption-frame rate balance adjustment curve was plotted according to different game modes (such as combat mode and casual mode) and graphics card performance curves. Through real-time analysis of this curve, the system can precisely adjust the workload of the graphics card to ensure that both the smoothness requirements of the game screen are met and the energy consumption of the graphics card is optimized.

[0087] In this embodiment, the specific steps for performing future frame adaptation compensation calculations and energy consumption-frame rate balance adjustment based on the frame rate difference distribution curve, and constructing the energy consumption-frame rate balance adjustment curve are as follows: Frame rate compensation values ​​are obtained by performing future frame adaptation compensation calculations based on the frame rate difference distribution curve. Based on the frame rate compensation value, the power consumption adjustment analysis of the graphics card is performed to obtain the power consumption adjustment data of the graphics card with frame rate compensation. The power consumption adjustment data of the graphics card is adjusted to balance power consumption and frame rate, and a power consumption-frame rate balance adjustment curve is constructed.

[0088] In this embodiment, based on the frame rate difference distribution curve, the system performs future frame adaptation compensation calculations to predict the rendering requirements of future frames and adjust the graphics card load accordingly, thereby achieving more precise energy consumption optimization. The frame rate difference distribution curve reflects the fluctuation between the actual game frame rate and the theoretically adapted frame rate. These differences exhibit certain distribution patterns, which the system can use to perform future frame adaptation compensation calculations.

[0089] Based on historical frame rate difference data, the system predicts frame rate trends over a future period using time series prediction methods (such as Autoregressive Moving Average (ARMA) or Long Short-Term Memory (LSTM) models). These methods can infer potential future frame rate differences based on the temporal characteristics of these differences, thus predicting the frame rate requirements for the next frame or several frames in the future. For example, if the frame rate difference has been gradually increasing over the past few seconds, the system may predict that the frame rate will remain low for the next few frames, requiring adaptive compensation to prevent over-rendering by the graphics card.

[0090] Based on the prediction results, the system will calculate a frame rate compensation value, which is the amount of adjustment needed to the current frame rate to ensure that the graphics card can better adapt to the game's visual requirements in the next few frames. For example, if the predicted future frame rate will be lower than the theoretical adaptation range (e.g., the actual frame rate is 45 FPS, while the theoretical range is 60-120 FPS), the system may calculate a compensation value (e.g., +15 FPS) based on the compensation algorithm. This means that by adjusting the graphics card load, the system attempts to improve future rendering performance to meet the expected frame rate requirements.

[0091] After calculating the frame rate compensation value, the system needs to adjust and analyze the graphics card's power consumption to ensure that the graphics card can achieve the desired frame rate target without increasing power consumption excessively. The graphics card's power consumption is mainly affected by the following factors: operating frequency, rendering load, memory usage, and GPU computing demands. The frame rate compensation value represents the system's need to increase or decrease the graphics card's rendering load to meet the rendering requirements of future frames, and there is a certain non-linear relationship between graphics card power consumption and rendering load.

[0092] To perform energy consumption adjustment analysis, the system first needs to establish an energy consumption model that describes the relationship between the graphics card's workload and energy consumption. Typically, this model can be built based on power measurement data and load variation data. For example, under high load conditions, the graphics card's power consumption increases exponentially, while under low load conditions, the power consumption changes less. Through experimental measurements, the system can establish such a model, defining the functional relationship between the graphics card's power consumption and its operating frequency.

[0093] Once the power consumption model is established, the system will adjust the GPU load based on the frame rate compensation value. If the compensation value requires increased rendering capabilities, the system will increase the GPU's operating frequency to achieve the desired frame rate in future frames. Conversely, if the compensation value requires reduced load, the system will moderately reduce the GPU frequency to decrease power consumption. For example, if the calculated frame rate compensation value is +15 FPS, the system might increase the GPU core frequency by 5%, thereby improving computing power and ensuring a stable achievement of the target frame rate in the next few frames.

[0094] After completing the power consumption adjustment analysis of the graphics card, the system needs to balance and adjust the relationship between the graphics card's power consumption and frame rate to ensure that the graphics card can provide the best image quality while achieving the lowest power consumption in different game scenarios. The key to this step is to construct a power consumption-frame rate balance adjustment curve by analyzing the relationship between the graphics card's power consumption data and the actual frame rate, and dynamically adjust the graphics card's working state according to this curve.

[0095] The power consumption-frame rate balance curve describes the trade-off between graphics card power consumption and game frame rate. This curve typically exhibits the following characteristics: in the low frame rate range, the graphics card consumes less power; in the high frame rate range, the graphics card's power consumption increases more rapidly. The system statistically analyzes power consumption at different frame rates to obtain the following typical states: Low frame rate and low power consumption range: At this time, the graphics card load is low, the game graphics requirements are small, the graphics card maintains a low frequency, and saves power consumption.

[0096] Medium frame rate balance range: The graphics card maintains a moderate operating frequency, providing a balance between frame rate and power consumption output.

[0097] High frame rate and high power consumption range: In order to meet the high frame rate requirements, the graphics card load is large and the power consumption increases accordingly.

[0098] The system can obtain data from these different regions through experiments, and then use fitting methods (such as least squares fitting, curve interpolation, etc.) to form a continuous curve of the graphics card's power consumption data under different loads and frame rates. This curve can help the system determine how to adjust the graphics card's operating frequency to achieve the optimal balance between power consumption and frame rate under different game scenarios and loads.

[0099] For example, in combat mode, the graphics card needs to output a higher frame rate (such as 90-120 FPS). At this time, the system may choose to increase the working frequency of the graphics card to meet the high frame rate requirement based on the power consumption-frame rate power consumption and frame rate balance adjustment curve. In casual mode, the graphics card may only need a lower frame rate (such as 30-60 FPS), and the system will save power by reducing the frequency of the graphics card.

[0100] The system will monitor frame rate, load, and power consumption data in real time, and dynamically adjust the graphics card's operating frequency according to the aforementioned adjustment curves. This ensures that the gaming experience is not affected while minimizing power consumption. For example, during intense battles, the graphics card operates under high load, and the adjustment curve may indicate a higher power consumption requirement; while in static scenes, the adjustment curve will suggest that the graphics card reduce its frequency to maximize energy efficiency.

[0101] In this embodiment, step S5 includes the following steps: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, the rendering power requirement is calculated to generate the rendering power consumption value. Dynamic resource scheduling data is obtained by dynamically scheduling the graphics card computing units based on the energy consumption value of rendering requirements. Automatically switch rendering modes based on dynamic resource scheduling data to generate intelligent rendering switching strategies; Dynamic control of graphics card power consumption is achieved through power consumption-frame rate balance adjustment curves and intelligent rendering switching strategies.

[0102] In this embodiment, the rendering power requirement is calculated by combining a graphics card power consumption map and a real-time rendering difficulty value. The graphics card power consumption map is typically provided by the graphics card manufacturer or derived through experimental measurement. The table records the power consumption of the graphics card under different operating frequencies, loads, and rendering tasks. For example, under low load, the graphics card's power consumption may be low (e.g., 30W), while under high load (e.g., high-quality scenes or complex physics simulations), the power consumption will increase significantly (e.g., 150W). This data provides the basis for the calculation. The real-time rendering difficulty value is a value assessed based on the complexity of the current game scene. It considers factors such as the number of objects, details, lighting effects, and physics simulations in the scene. The rendering difficulty value for each scene is dynamically adjusted as the game scene changes. For example, in a high-intensity battle scene, the rendering difficulty value will increase significantly, while in a static background or simple scene, the rendering difficulty value will be lower. By combining the graphics card power consumption map with the real-time rendering difficulty value, the system can calculate the rendering power requirement required for the current frame. This requirement value reflects the power required by the graphics card to achieve the current rendering goal. For example, if the current game scene rendering difficulty is 0.8, the graphics card's power requirement at this difficulty level might be 80W, while at a difficulty level of 1.2, the power requirement might increase to 120W. The calculation of rendering power consumption takes into account the graphics card's current operating status, frequency, scene complexity, and graphics rendering requirements. This rendering power consumption value will serve as the basis for subsequent resource scheduling and dynamic optimization.

[0103] After calculating the rendering power consumption requirement, the system dynamically schedules the graphics card's computing units based on this value. A graphics card typically contains multiple computing units, such as graphics processing units (GPU cores), rasterization units, and texture processing units. Each computing unit has a different load and power consumption, and these can be dynamically allocated according to demand. The dynamic resource scheduling method of the graphics card usually relies on scheduling strategies, including enabling and disabling computing units, frequency adjustment, and load balancing. For example, if the current rendering power consumption requirement is low, the system can choose to shut down some computing units and reduce the frequency, thereby reducing the graphics card's power consumption. When the rendering demand is high, the system will enable more computing units and increase the graphics card's frequency to meet the rendering task requirements. By analyzing the current rendering power consumption requirement, the system can accurately calculate the utilization rate of each computing unit and dynamically adjust the allocation of computing units. For example, in some complex dynamic scenes, the graphics card's rendering power consumption requirement may be high. In this case, the system will mobilize more computing units and accelerate the core frequency to meet the high demand; while in low-demand scenes, the system may reduce the use of some computing units and maintain a lower operating frequency. This dynamic scheduling effectively balances graphics card performance and power consumption, preventing excessive energy waste under low load. The dynamic resource scheduling data includes information such as the status of each computing unit, its enable / disable flag, and operating frequency. This data can be used for further scheduling strategies and optimization decisions, providing necessary support for automatic rendering mode switching and energy efficiency management.

[0104] By analyzing and processing dynamic resource scheduling data, the system can automatically switch rendering modes, intelligently adjusting the graphics card's operating mode according to the different needs of the game scene. The load requirements of the graphics card may vary significantly in different game scenes. For example, in combat mode, the game scene is complex, resulting in a high rendering load; while in casual or observation mode, the rendering load is lower. The graphics card needs to dynamically switch rendering modes based on these changes to maximize energy efficiency while ensuring visual effects. By monitoring real-time rendering requirements and resource scheduling, combined with an energy consumption mapping table and rendering difficulty values, the system can determine the appropriate rendering mode for the current game scene. For example, when the game load is low, the system may switch to a "low-power" rendering mode, in which the graphics card frequency is lower and some computing units are shut down; while when the load increases, the system will automatically switch to a "high-performance" rendering mode, increasing the graphics card frequency and the number of computing units to ensure smooth rendering. This automatic rendering mode switching strategy makes decisions based on real-time analysis of dynamic resource scheduling data and rendering demand energy consumption values. By evaluating the performance and energy efficiency of each rendering mode, the system generates an intelligent rendering switching strategy that can quickly respond to load changes and adjust the graphics card's operating mode. For example, in combat mode, the system selects a high-performance mode, while in static or low-activity modes, it selects a low-power mode. This strategy not only reduces graphics card power consumption but also improves performance without sacrificing the gaming experience.

[0105] By combining the energy consumption-frame rate energy consumption and frame rate balance adjustment curve with intelligent rendering switching strategies, the system dynamically regulates the graphics card's energy consumption. The energy consumption-frame rate energy consumption and frame rate balance adjustment curve is constructed based on historical frame rate and energy consumption data, describing how the graphics card's energy consumption changes under different frame rate requirements. Through this curve, the system can accurately determine how to minimize energy consumption while ensuring smooth gameplay in different game scenarios. During gameplay, the system acquires the game's frame rate requirements in real time and adjusts the graphics card's operating mode according to the intelligent rendering switching strategy. Simultaneously, the system also refers to the energy consumption-frame rate energy consumption and frame rate balance adjustment curve to finely control the graphics card's load. For example, when the graphics card's load is low, the system uses the adjustment curve to predict the energy consumption requirements for the next few frames and adjusts the graphics card's frequency accordingly to reduce unnecessary power consumption; while under higher rendering requirements, the system increases the graphics card's frequency to improve performance. Through this dynamic adjustment, the graphics card can automatically adapt to different game requirements, maximizing energy efficiency. For example, in high-intensity combat scenarios, the graphics card will run at a higher frequency to ensure a smooth gaming experience; while in low-load scenarios, the graphics card frequency will be reduced to minimize energy waste.

[0106] In this embodiment, an intelligent power consumption regulation system for a graphics card component is provided, used to execute the intelligent power consumption regulation method for the graphics card component as described above, including: The screen power consumption calculation unit is used to obtain the graphics card operating status information; and to perform game screen power consumption calculation based on the graphics card operating status information to obtain a graphics card power consumption value mapping table. The rendering difficulty calculation unit is used to collect game client operation logs based on the game client operation logs; and to calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value. The intent recognition unit is used to acquire the player's operation command stream; based on the player's operation command stream, it performs deep recognition of the player's operation intent to obtain the real-time operation intent; The frame rate balancing unit is used to analyze the frame rate required by the game screen according to the real-time operation intention and adjust the energy consumption-frame rate energy consumption and frame rate balance, and build an energy consumption-frame rate energy consumption and frame rate balance adjustment curve. The dynamic power consumption control unit is used to dynamically schedule the graphics card computing unit based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, and to perform dynamic power consumption control of the graphics card by combining the power consumption-frame rate power consumption and frame rate balance adjustment curve.

[0107] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0108] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein are implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for intelligent power consumption regulation of a graphics card component, characterized in that, Includes the following steps: Step S1: Obtain graphics card operating status information; Based on the graphics card operating status information, the game screen energy consumption is calculated to obtain a graphics card energy consumption value mapping table; Step S2: Collect game client operation logs based on the game engine interface; calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value; Step S3: Obtain the player's operation command stream; Based on the player's command stream, deep recognition of the player's operation intent is performed to obtain the real-time operation intent; Step S4: Analyze the game screen frame rate requirements and adjust the energy consumption-frame rate balance based on the real-time operation intention, and construct the energy consumption-frame rate balance adjustment curve. Step S5: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, dynamically schedule the graphics card computing units, and combine the power consumption-frame rate power consumption and frame rate balance adjustment curve to perform dynamic control of graphics card power consumption.

2. The intelligent power consumption regulation method for a graphics card component according to claim 1, characterized in that, The specific steps of step S1 are as follows: The system detects when the computer enters the game and obtains the graphics card's operating status information through the graphics card driver interface. Calculate the real-time power consumption data of each GPU component based on the graphics card operating status information; Identify multi-frame rendered scenes of a game; calculate the peak power, energy integral, and power fluctuation rate of the multi-frame rendered scenes of the game, calculate the density index, and obtain the graphics card energy consumption value of a single frame. The game's multi-frame rendered footage is categorized by frame type to obtain frame type labels; the frame type labels include battle scenes, cutscenes, and menu interfaces. Based on the image type label, the graphics card power consumption value of a single frame is associated and matched to obtain a graphics card power consumption value mapping table for multiple image types.

3. The intelligent power consumption regulation method for a graphics card component according to claim 1, characterized in that, The specific steps of step S2 are as follows: Collect game client runtime logs based on game engine interface; Game scene elements are decomposed and identified based on the game client's operation logs, and scene element indicators are extracted; the scene element indicators include the number of visible triangles, the number of dynamic objects, the number of light sources, and the number of active particle emitters. Visual rendering features are obtained by calculating image gradient complexity, color information entropy, proportion of high-frequency texture components, and transparency channel based on scene element indicators. The difficulty of real-time image rendering is calculated based on the visual rendering features to obtain the real-time image rendering difficulty value.

4. The intelligent power consumption regulation method for a graphics card component according to claim 1, characterized in that, Step S3 is as follows: Obtain the player's operation command stream; calculate the operation frequency based on the player's operation command stream to obtain the timing operation frequency; Calculate the periodic frequency distribution and operation intensity based on the timing operation frequency; Based on the periodic frequency distribution and operation intensity, instruction continuity is identified to obtain the continuous characteristics of operation instructions; Based on the continuous features of operation instructions, the player's operation intent is deeply identified to obtain the real-time operation intent; The real-time operation intent includes combat mode, static mode, casual mode, and game interface control mode.

5. The intelligent power consumption regulation method for a graphics card component according to claim 1, characterized in that, The specific steps of step S4 are as follows: The game screen frame rate range required by the real-time operation intention is calculated to obtain the theoretically adapted screen frame rate. Calculate the real-time frame rate of the game screen; Define a short-term calculation period, and calculate the periodic average of the real-time frame rate of the game screen according to the short-term calculation period to obtain the actual game frame rate; The frame rate difference is calculated by performing a frame rate difference calculation on the actual game frame rate based on the theoretically adapted frame rate; Timing tracking statistics are performed based on the frame rate difference to obtain the frame rate difference distribution curve; Based on the frame rate difference distribution curve, future frame adaptation compensation calculation and energy consumption-frame rate balance adjustment are performed to construct the energy consumption-frame rate balance adjustment curve.

6. The intelligent power consumption regulation method for a graphics card component according to claim 5, characterized in that, The specific steps for performing future frame adaptation compensation calculations and energy consumption-frame rate balance adjustment based on the frame rate difference distribution curve, and constructing the energy consumption-frame rate balance adjustment curve are as follows: Frame rate compensation values ​​are obtained by performing future frame adaptation compensation calculations based on the frame rate difference distribution curve. Based on the frame rate compensation value, the power consumption adjustment analysis of the graphics card is performed to obtain the power consumption adjustment data of the graphics card with frame rate compensation. The power consumption adjustment data of the graphics card is adjusted to balance power consumption and frame rate, and a power consumption-frame rate balance adjustment curve is constructed.

7. The intelligent power consumption regulation method for a graphics card component according to claim 1, characterized in that, The specific steps of step S5 are as follows: Based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, the rendering power requirement is calculated to generate the rendering power consumption value. Dynamic resource scheduling data is obtained by dynamically scheduling the graphics card computing units based on the energy consumption value of rendering requirements. Automatically switch rendering modes based on dynamic resource scheduling data to generate intelligent rendering switching strategies; Dynamic control of graphics card power consumption is achieved through power consumption-frame rate balance adjustment curves and intelligent rendering switching strategies.

8. An intelligent power consumption regulation system for a graphics card component, characterized in that, The method for performing intelligent power consumption regulation of a graphics card component as described in claim 1 includes: The screen power consumption calculation unit is used to obtain the graphics card operating status information; and to perform game screen power consumption calculation based on the graphics card operating status information to obtain a graphics card power consumption value mapping table. The rendering difficulty calculation unit is used to collect game client operation logs based on the game client operation logs; and to calculate the rendering difficulty of the screen content based on the game client operation logs to obtain the real-time screen rendering difficulty value. The intent recognition unit is used to acquire the player's operation command stream; based on the player's operation command stream, it performs deep recognition of the player's operation intent to obtain the real-time operation intent; The frame rate balancing unit is used to analyze the frame rate required by the game screen according to the real-time operation intention and adjust the energy consumption-frame rate energy consumption and frame rate balance, and build an energy consumption-frame rate energy consumption and frame rate balance adjustment curve. The dynamic power consumption control unit is used to dynamically schedule the graphics card computing unit based on the graphics card power consumption value mapping table and the real-time image rendering difficulty value, and to perform dynamic power consumption control of the graphics card by combining the power consumption-frame rate power consumption and frame rate balance adjustment curve.

Images