Why the 2019 16-inch MacBook Pro slows down a few minutes into a game, and how to keep it from happening

The SMC, the system controller inside the T2 chip, cuts the power. The charger, the AMD driver, ACPI and the chip temperatures are not the cause.
It gives the CPU and GPU one shared power budget: about 82 W when cold, falling as the case warms, to roughly 65–72 W in our capped runs and as low as 54–60 W under full stock load.
The budget is fixed in Apple's signed SMC firmware. No setting, SMC key or driver option raises it.
The fix is to stay under it: GPU capped at 32 W, CPU capped at 1700 MHz, the game in Borderless. That ran BF6 with no cut at all and a median of 53 FPS.

How the limit works

One budget, four stages of enforcement

The SMC's zone-0 controller compares two values every second. When the draw stays above the budget, it steps in, harder each stage. Windows, ACPI and the AMD driver only pass its decisions on.

1
PZ0F is the smoothed CPU + GPU draw in watts. PZ0E is the budget. It starts at ~82 W and falls as the case sensors warm past their targets, mostly Ts2S past 45 °C.
2
While PZ0F is above PZ0E, PZ0T climbs. It adds up the overshoot, roughly 0.5–1.3 per second.
3
GPU steps. MSLG rises and reaches the GPU as EGPS: the power limit drops 50 → 45 → 40 → 35 → 30 W, each step 10 % of the power table's limit.
4
Hidden CPU cut. MSLC (0–24) slows the real CPU clock from 2300 to about 800 MHz. HWiNFO and ThrottleStop still show 23x, so it looks like nothing happened.
5
PROCHOT. When MSLC is at 24 and PZ0T reaches ~98, the CPU drops to 8x and the GPU to 300 MHz: ~10 FPS, in pulses of 4–8 s.

Evidence

Draw against budget, four runs

Each panel is one BF6 session, logged once a second from the SMC. The first two go over the budget and get cut. The last two stay under it and never do. Same game, same map, same machine; only the caps differ.

Seconds from the start of logging, sampled every 5 s. The 01:41 run predates PZ0F logging, so only the budget and PZ0T are shown. PROCHOT times come from HWiNFO, aligned to the SMC log by matching the GPU temperature in both. Runs 01:41–09:51 used a driver-flag bypass; 11:15 used the stock driver.

What fooled us

Three things that looked like the problem and weren't

HWiNFO's effective clock collapses while the CPU is fine

08:51 run. From about 8:54 HWiNFO reports the cores at 50–100 MHz and 2–5 % active, while Windows' own counters show them 70–80 % busy at 2300 MHz, and the game holds 60 FPS. The real CPU cut (MSLC, from 8:56) only shows in typeperf. Real clock = % Processor Performance × 2300 MHz.

Fullscreen cost 60 % of the frame rate

10:18 run, same power settings throughout. At 10:28:58 BF6's display mode was switched from Fullscreen to Borderless mid-match: GPU time per frame fell from ~45 ms to ~15 ms and FPS rose from ~22 to 56–60. Several slow runs earlier that morning were this setting, not the power limit.

And a network mouse. Synergy, the tool sharing a keyboard and mouse over the network, dropped input now and then. It looked exactly like the CPU stalling. typeperf showed the CPU running normally each time.

The fix

Stay under the warm budget

Nothing raises the budget, so the fix lowers the draw. Each cap was found by moving it until the SMC stopped cutting.

32 WGPU power limit (soft PowerPlay table)

1700 MHzCPU cap (Windows power plan maximum frequency)

flag 1AMD driver left stock, no bypass

BorderlessBF6 display mode, Low preset

Result, 11:15 run: CPU 17x at ~19 W, draw peaked at 65.6 W, budget bottomed at 70.2 W and then rose to 72 W. PZ0T, MSLC and MSLG stayed at 0. FPS median 53, 10th percentile 47, 1 % lows ~35.

Run	GPU	CPU	Driver	Draw vs budget	SMC	FPS
08:37	30 W	PL1 20 W	bypass	~69–70 W, budget 82 → 75 W	no cuts	40–57
08:51	35 W	PL1 20 W	bypass	~77 W over ~67 W	MSLC 24, PROCHOT	60, drops to 24
09:40	32 W	PL1 20 W, not clamped	bypass	~72 W over ~65 W	MSLC 22–23, PROCHOT	52–60, dips to 25
09:51	32 W	PL1 20 W, clamped	bypass	~65–66 W under ~71 W	no cuts	50–59
10:18	32 W	1800 MHz	stock	~65–67 W met ~65.3 W	PZ0T 17, no steps yet	50–60 (Borderless)
10:58	32 W	1600 MHz (ran 1500)	stock	~60–61 W under 68.6–71 W	no cuts	dips in busy scenes
11:15	32 W	1700 MHz	stock	65.6 W peak under 70.2 W low	no cuts	median 53

Not proven yet

The 11:15 run was ~7 minutes of play. A 15-minute confirmation is still owed.
Every run used a MorePowerTool table that also lowers the GPU's maximum voltage to 950 mV. The version being built changes only the power limit, at stock voltage, so it may draw a little more.
One machine, one game, one room. 30 W is the safer GPU setting for a hot room, judged from its larger margin; no hot-room run was made.

The hunt

Everything else we tried

The SMC firmware was reverse-engineered as part of this research. That is how we know the budget is fixed in the firmware and that no key or setting raises it. That work is kept in a separate private repository and is not published.

ACPI. It relays the SMC's bytes to Windows; no method writes them.
AMD PowerPlay and VBIOS. The cut is a forced power state applied on top of the table.
Writing SMC keys. A new PZ0E is overwritten within a second; no key holds the ceilings. One key pair can freeze the budget; a guarded test is written but has not run yet.
EFI settings. Its CPU power limit is the same register ThrottleStop writes.
The charger. Already Apple's 96 W, the most this model takes.
Chip temperature. PROCHOT fired with the GPU hot spot under 95 °C.
Case temperature as the trigger. Same Ts0S, no cut while the draw is under budget. It only sets the budget.
Bypassing the GPU steps. With the driver flag at 0 the GPU ignores MSLG, so the SMC goes straight to MSLC and PROCHOT.
Turbo off. Unplayable.
Patching the SMC firmware. Signed and verified by the T2. Studied, not attempted.

Status

The fix is being built into gamebooster-rs for owners who have never used MorePowerTool or ThrottleStop: one program that installs the 32 W GPU table, caps the CPU only while BF6 runs, and keeps BF6 in Borderless. It changes nothing on any other machine. Linux was not measured; its AMD driver ignores the SMC's GPU steps, so it would likely behave like the bypass runs.