Repository navigation
soc: apple: clpc, drm/asahi: g17: busy-share memory floor and light effort for T6041 - #1369
Open
AxxzyWasTaken wants to merge 4 commits into
Open
AxxzyWasTaken wants to merge 4 commits into
AxxzyWasTaken wants to merge 4 commits into
Conversation
Contributor
On T6040 and T6041 any reported GPU work holds the top memory and fabric floor. At 120 Hz a scrolling browser keeps the GPU reported busy most of the time for a few percent of real execution, so light desktop use pays for the top DCS state. Let the GPU driver report its busy share per window with apple_clpc_gpu_set_busy() and pick the floor from a per-SoC table in struct apple_clpc_hw: on T6040/T6041 DCS 1, 2, 4 or 5 and fabric 0, 0, 0 or 2, split at gpu_busy_mid (160), gpu_busy_high (500) and gpu_busy_top (800) permille. A higher level applies at once. A lower one applies at the first CLPC sample at least 400 ms after the last sample that asked for the current level or a higher one, so the down-step happens at least 400 ms after the last change, later if the sampler runs late. A GPU that reports no share, and every SoC without the table, keeps the top of the map. The debugfs status shows the reported share and the current level without moving it. The CPU side had the same problem: a cluster at its own top speed asked for DCS 5 and fabric 2 even when that was the E cluster. Take the map quarters from 4.512 GHz for both clusters, and lower the T6040 map to DCS 1, 1, 3, 4 with fabric 0. On the M4 Max on AC, compared with the old table: scrolling 24.9 W to 22.1 W at 120 fps with no long frames, a page workload 23.84 W to 22.73 W for 0.9 % less score. The CLPC host demand test now covers the busy-share table, a GPU that reports no share and the down-step hold. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
Sum the engine time every client is charged and report its share of a 200 ms window to CLPC, which then keeps the top memory and fabric floor for GPU work that really is busy. The same windows drive a light effort governor. Four quiet windows in a row (under 35 % busy, no job of 3 ms or more) drop the firmware to half effort, and 75 % busy or a 7 ms job goes back to full. Light effort runs the same work about twice as long, so the way out sits at about twice the way in, or work that fits light effort sticks at full. The share sent to CLPC is doubled at full effort so one floor table fits both. note_submission() returned effort_full, so the lockless path skipped the governor. It now takes the slow path when the governor wants light. g17_light_effort (65536 is full, 0 turns this off), g17_light_enter, g17_light_exit, g17_light_job_enter_us and g17_light_job_exit_us are runtime parameters. Effort sweep on the M4 Max with a 1080p30 clip: full 14.0 W, 32768 10.4 W, and below 50 % gained nothing. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
AxxzyWasTaken
force-pushed
the
max-gpu-power-v2
branch
from
November 12, 2026 20:48
1257b68 to
37559c1
Compare
This was referenced Nov 12, 2026
RyanTheTide
requested changes
Nov 12, 2026
RyanTheTide
left a comment
Contributor
There was a problem hiding this comment.
@AxxzyWasTaken thanks for the rebase and the power numbers. Three things before this can go in:
- apple_clpc_hw_t6040 is also the M4 Pro's table. The CPU map change (DCS 1,1,3,4 and fabric 0,0,0,0 at the top, and level_khz for the E cluster) lowers the memory floor a busy CPU gets on the M4 Pro, where the comment above the table measures 237-242 GB/s at DCS 5 / fabric 2. Please give T6041 its own table and leave T6040 as it is, or add M4 Pro measurements. We can run the M4 Pro side if you split it.
- The light-effort governor is in the shared G17 code and on by default, so it also changes the A18 Pro and M4 Pro. A 120 fps game reads about a third busy, under the 350 entry point, and stays under the 750 exit point once it runs at half effort. Please scope it per SoC (match data, T6041 first) until it has frame-time results on games, not only power.
- Please replace the five g17_light_* module parameters with per-SoC values, as was done for the CLPC thresholds.
Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
…t effort to T6041 The M4 Pro shares the CLPC compatible and the G17 code with the M4 Max, so both changes reached it unmeasured. Give T6041 its own CLPC table, picked on an "apple,t6041" machine, and leave apple_clpc_hw_t6040 as integration/aurora has it. Move the light effort thresholds from five module parameters into the per-SoC G17 Config, set only for T6041; other SoCs run every submission at full effort and report the busy share unscaled. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
Contributor
Author
|
Thanks. All three are in 33db416, on top of a merge of the current integration/aurora (e6588ee, clean).
Tested: Image and modules build at |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #1089, rebased onto current integration/aurora as requested. The review asked for a reworded commit message ("at least 400 ms"), which needs new history, so this is a new branch; #1089's branch is left as it was.
Lowers power on the M4 Max in everyday use. On T6040/T6041, any reported GPU work holds the top memory and fabric floor, and the GPU runs at full effort for quiet work.
struct apple_clpc_hw(DCS 1, 2, 4, 5 and fabric 0, 0, 0, 2, split atgpu_busy_mid160,gpu_busy_high500 andgpu_busy_top800 permille). Going down happens at least 400 ms after the last change. CPU map quarters now use 4.512 GHz for both clusters, and the T6040 map is lower.note_submission()no longer skips it.Effort sweep on a 1080p30 clip: full 14.0 W, half 10.4 W.
Changes since #1089 (review by RyanTheTide):
gpu_busy_top,gpu_busy_highandgpu_busy_midareapple_clpc_hwfields next togpu_busywith the same values for T6040/T6041, no longer 0644 module parameters.apple_clpc_status_show()readsgpu->busy,busy_validandlevelunder the lock and no longer callsapple_clpc_gpu_level(), so reading debugfs can't move the level.tools/asahi/clpc-gpu-demand-tests.pyextractsapple_clpc_gpu_level(), has amax_tmacro and the newstruct apple_clpc_gpufields, and adds cases for no share reported, belowgpu_busy_mid, between the thresholds, the 400 ms down-step hold and its restart, plus three negative controls.struct apple_clpc_hwand the T6040 table keep both the ANE fields and the busy-share fields. The T6040 comments that said a busy CPU cluster or GPU work gets DCS 5 / fabric 2 now match the new tables. The CPU map is unchanged from soc: apple: clpc, drm/asahi: g17: busy-share memory floor and light effort for T604x #1089.Tested: the logic has been the daily setup on my M4 Max since 5 Nov (7.3.0), with no GPU recoveries from it. For this exact head:
python3 -I tools/asahi/run-host-tests.py --onlywith clpc, usage, g15-queue-credit, asahi-m4 and g17 passes (35 runs), and the CLPC demand test passes with all 15 negative controls.drivers/soc/apple/clpc.oanddrivers/gpu/drm/asahi/g17/clpc.obuild with LLVM=1 W=1 with no new warnings. Not done: KUnit was not run, and before the rebase this head had not been booted.Built and booted, 12 Nov (the whole kernel, Rust drm/asahi included): rebased onto
integration/aurorac6e08489, whereclpc.candg17/mod.rsconflicted. The GPU demand takes the busy-share column but never goes below a chip's new.gpuminimum;note_submission()keeps the newnote_waiters()call and takes its effort fromsubmission_effort(). The CLPC demand test passes with all its negative controls. This code is my daily kernel now on the M4 Max, together with #1664: a deep sleep, a desktop logout after the wake, and a game session, with theg17_light_*parameters taking effect and no GPU errors or recoveries in the log.Please check:
aurora.g17_light_effort=0turns it off. Tell me if you'd rather have it scoped to T604x.