How Performance Modes Work on Asus Laptops

Every Asus gaming laptop ships with the same three performance modes: Silent, Balanced and Turbo. Armoury Crate shows them. G-Helper shows them. The fan key on the keyboard cycles them. But none of these apps own the modes. They are part of the laptop itself, and every tool that switches them is pressing the same three buttons on the same machinery.

This page takes the thing apart, layer by layer: what lives in the firmware, what lives in Windows, and where your tweaks go when you add them. Everything here is taken from G-Helper’s source code, which is open and readable, and it applies to Armoury Crate just the same, because both apps drive the laptop through the same official Asus interface. If you would rather have the short, non-technical version, read How G-Helper works instead.

A mode is a stack, not a switch

Picking Turbo feels like flipping one switch. Under the hood it is a small stack of settings applied together. The bottom two layers come with every mode on every laptop, and a machine on factory settings never uses anything else. The top three exist only if you set them up: that optional territory is what Armoury Crate groups under its Manual mode, and what G-Helper attaches to modes as custom settings.

None of the apps in this picture run your hardware in real time. They pick a preset and hand over numbers, and the firmware, Windows and the drivers do the actual running, the same way they do on a laptop that has never seen a tuning app. That is why a mode keeps working with the app closed, and why G-Helper and Armoury Crate set to the same thing behave the same.

The rest of the page goes through the stack from the bottom up, ending with the exact apply order and a table of the real endpoints.

Layer 1: the firmware preset

Silent, Balanced and Turbo are presets that Asus bakes into each laptop’s firmware at the factory. Each preset carries its own fan tables, power limits and boost behaviour, tuned per model. That is why Turbo on a 14 inch Zephyrus does not behave like Turbo on an 18 inch Strix. The preset belongs to the laptop, not to the app.

Selecting one is a single firmware call. The app writes one number to one ACPI endpoint, 0x00120075, reachable through the ATKACPI device that Asus’s own driver package provides, and the firmware takes it from there.

The numbering is Asus-specific: the menu order is Silent, Balanced, Turbo, but the firmware counts Balanced 0, Turbo 1, Silent 2. Vivobook and Zenbook models take the same numbers on a different endpoint, 0x00110019.

Custom modes are not new firmware modes either. A custom mode in G-Helper is one of the three normal presets underneath, plus your saved overrides from the layers above.

Layer 2: the Windows power mode

A performance mode is not only a firmware affair. Windows has its own idea of how hard to push the CPU: the power mode you see when you click the battery icon, with its three steps, Best power efficiency, Balanced and Best performance. Technically these are overlays on top of the active power plan, each with its own GUID, set through the same Windows API the battery flyout uses.

Every time the performance mode changes, the matching Windows mode is set with it. Silent brings Best power efficiency, Balanced brings Balanced, Turbo brings Best performance. The plan underneath is the Balanced plan, and that is not a tweak: it is the plan Windows ships active on every machine, and modern Windows only applies the overlays there. G-Helper checks before touching it and sets it only if something else is active, so on a normal system the plan simply stays on its factory default. Armoury Crate keeps the exact same pairing, which is why the battery icon mode jumps around when you switch modes in either app.

So the firmware decides how much power the silicon may draw and how the fans behave, and Windows decides how eagerly it schedules and boosts the CPU. Silent feels like Silent because both halves move together. G-Helper lets you re-pair them per mode, or pin the old High performance plan instead. The CPU boost policy, the Windows setting for how the CPU is allowed to turbo, is handled the careful way: by default G-Helper only reads it and shows it, and writing a different value is opt-in, per mode. The one thing it will not do is fight Battery saver: while that is on, Windows wins.

Layer 3: power limits, fan curves and GPU power

From this layer up, everything is optional. A laptop on factory settings has none of it active, and a plain Silent, Balanced or Turbo never touches it. In Armoury Crate this territory sits behind its Manual mode; in G-Helper it is the custom settings you attach to a mode. Everything in this particular layer still goes to the same place as layer 1: the firmware, over Asus’s own endpoints. The firmware checks every value against its own limits, so a number it does not like is clamped or ignored rather than obeyed.

CPU power limits are three watt values with awkward names. SPL is what the chip may draw indefinitely. sPPT is what it may hold for a couple of minutes before settling down. fPPT is the short first burst. Intel people know the first two as PL1 and PL2. Each one is a single ACPI write, watts in, and the firmware enforces it from then on. Models that pair an AMD CPU with an AMD GPU take a separate CPU-only limit instead of the boost values.

Fan curves are exactly 16 bytes per fan: eight temperature points and eight fan percentages. Sending one does not move fan control into the app. The fans stay under the firmware’s embedded controller at all times, and that is the manufacturer’s design, not a limitation of any tool. The EC takes your eight points and interprets them itself: how it blends between them, how quickly it reacts, when it spins down. No app on these laptops drives a fan directly, G-Helper included. That is why a custom curve keeps working while the app sits idle, and why two models can treat the same curve a little differently. The stock curve of every preset can also be read back from the firmware, which is how G-Helper shows it to you before you bend it.

GPU power on Nvidia models is three more firmware values: extra watts on top of the GPU’s base TGP, the Dynamic Boost headroom it may borrow when the CPU is not using its share, and a thermal target between 75 and 87 degrees that the GPU tries to stay under. These shape how two laptops with the same GPU chip end up performing very differently, and they are firmware values, not driver ones.

Layer 4: Nvidia clock offsets

Clock offsets are the one mainstream tweak that does not go through Asus at all. A core or memory offset goes to the Nvidia driver through NvAPI, as a plus or minus on the GPU’s maximum performance state. It is the same call MSI Afterburner makes. The driver stays in charge of the actual clocks, the offset just shifts its targets. G-Helper can also cap the maximum GPU clock, useful for quiet and efficient gaming, through the driver’s locked clocks feature, the same thing nvidia-smi -lgc does from the command line.

Since this layer lives in the driver, it is simply skipped when the dGPU is powered off in Eco mode. The Eco / Standard / Ultimate switch itself, for the record, is not part of a performance mode. It is a separate hardware toggle for the dGPU and the MUX, with its own endpoints, and it stays put when modes change.

Layer 5: AMD temp limit and undervolting

The last layer is completely optional. A performance mode works exactly the same without it, nothing else here depends on it, and most people never switch it on. It is also the only layer that leaves the official Asus road entirely. On AMD machines, G-Helper can set a CPU temperature limit, where the chip throttles itself to stay under your number, and apply Curve Optimizer undervolting to the CPU and the integrated GPU.

There is no Asus endpoint for any of that, and Armoury Crate has no equivalent. These settings go straight to the SMU, the management controller inside the processor, through its mailbox registers, using the signed PawnIO driver. It needs administrator rights, and on a few models the limit resets itself under load, so G-Helper quietly reapplies it on a timer. The SMU validates what it accepts, but this is still the most at-your-own-risk layer of the five, which is why it sits behind extra setup and is off by default.

Put together, the whole map looks like this:

What one click actually does

Here is the full sequence when you click Turbo, in source order:

The pauses are not laziness. Some firmware revisions ignore writes that arrive too quickly after a mode change, so the limits land about a second later. A few models get extra choreography on top: the 2024 G14 needs a bounce through another preset to properly drop old limits, some TUF models need their power limits pushed again a second after the fan curves, and a couple of machines get the whole power block re-sent five seconds later because the firmware quietly reverts it. The timeline above is the generic path.

It is also why running G-Helper and Armoury Crate side by side goes wrong. These are shared hardware registers, and the last writer wins: modes flip back on their own, fans ignore a curve you just set, limits change for no visible reason. One app at a time.

Armoury Crate does the same thing

None of this is a G-Helper invention, and none of it is a hack. The mode IDs, the endpoints, the Windows pairing: all of it is standard plumbing Asus put into these laptops, the same interface its own software sits on. Armoury Crate writes the same mode numbers to the same register, pairs the same Windows power modes, and feeds the same power limit and fan curve endpoints from its manual sliders.

The difference is the wrapping. One is a single small executable that sends a value when you click and then sits idle. The other is a platform of services that does the same writes, plus a great deal more, in the background. The hardware cannot tell which app asked, because in both cases the firmware is the one doing the actual work. For the practical comparison, see G-Helper vs Armoury Crate.

Reference: endpoints and IDs

For the curious, the actual values, straight from the source. Firmware settings are written with the ACPI DEVS method and read back with DSTS, through the ATKACPI device.

These IDs are not even Windows-specific. The Linux kernel drives the same firmware through the same numbers: its asus-wmi driver knows 0x00120075 as the throttle thermal policy, the full list of endpoints lives in asus-wmi.h under ASUS_WMI_DEVID_ names, and the newer asus-armoury driver exposes the tuning knobs natively on Linux. The borrowing has gone both ways: a good number of these endpoints, the CPU power limits and all of the GPU ones among them, were first mapped out in G-Helper and later picked up by the kernel.

The Windows half is two GUIDs deep:

Everything above can be checked in the G-Helper source: AsusACPI.cs holds the endpoints, ModeControl.cs the apply sequence, PowerNative.cs the Windows side, NvidiaGpuControl.cs the driver calls and RyzenSmu.cs the SMU commands, annotated with their counterparts in RyzenAdj and Universal x86 Tuning Utility, where the AMD mailbox side was originally worked out.

If this page made you want to try the layers yourself, the advanced settings guide covers the practical side, and the FAQ the basics.