[chriskearney]

This carries Eryk Wieliczko’s G15 submission and T6030 PMP work from #233 and #238 onto integration/aurora, repairing the host fixtures that blocked the original stack’s CI. The original four commits retain Eryk’s authorship, sign-offs and cherry-pick -x provenance; their stable patch IDs match the originals. The original PRs and branches remain untouched.

Original commits:

• d82144ad56a8: wrap G15 stamps through zero.
• 8525dd8e380a: acquire VM slots at publication and retain failed published bindings.
• 610cc54ad498: lock G15 mappings once per submit.
• 8824dd6a7aaa: report T6030 GPU power to PMP after backend initialization.

Behavior carried from #233: VM creation no longer reserves a hardware slot for the lifetime of each VM, removing the 63-live-VM cap. With robust_isolation=1, VMs can share the one execution slot with the existing ASID invalidation on switches. Queue and other resource limits still apply.

The follow-up repairs six host fixtures: PB growth models the current job slot/VM identity API; the zero-word golden changes only for removal of MAX_VMS and its comment; input-error tests exercise production binding/completion/prefix bodies; retention tests model the new PMP readiness service. Five new binding mutants and two new PMP mutants must compile and fail their intended runtime assertions. The J613 display/PMP fixture now supplies the OF lookups and rejects unexpected T6030 report calls. The PMP supplier fixture models the new GFX-report service under the existing lock, verifies error forwarding, and adds a mutant that discards its error. Its 33 runtime mutants compile and are killed; both controls pass across all three configuration combinations. Existing controls remain. Production follow-up edits only clarify ownership comments and format one match arm.

Validation at 5af49598aac5ac3d6925b69a900d5417f7e84bd9:

• The three original CI failures reproduce before the fixture fixes and pass afterward.
• All nine relevant G15 host suites pass through the repository CI runner: PB growth, input errors, zero words, retention, queue credit, probe initialization, maintained handoff, statistics drain and the G15 selftests (81 passed, 2 explicitly ignored). Mutation controls pass where provided; private hardware fixtures remain explicitly skipped.
• Retention covers 26 cases, including failed PMP readiness with/without orphan allocation and no PMP call on other platforms. Binding tests cover allocation refusal/retry, reuse, successful release, failed completion/last-reference retention and failure while appending to an already published prefix.
• Repository commit checks pass for all six commits; git diff --check passes. The two additional C suites also pass locally, making eleven relevant local suites.
• Full CI at 5af49598 passes: CI self-test, plan, all six commit checks, device trees, compile, both complete host-test groups, full kernel package (including the Rust driver), KUnit, emulated boot/module loading and result. Attestation is normally skipped on pull requests.

Hardware evidence remains the original stack’s evidence, documented in the #238 review. This rebased carry binary has not been booted. Host models do not qualify GPU scheduling, firmware timing or hardware ASID allocation.

Scope: shared G15 submission fixes apply to supported G15 paths. The PMP power/bandwidth fix is explicitly T6030 (M3 Pro); this is not an Air/Max performance claim or new board/firmware admission. Mesa #17 remains a separate PR: its extended Vulkan feature profile is G15S-specific, and its review evidence is recorded there. No firmware identities, display defaults or package pins are widened here. The separate J516C cold-boot review on #246 retains its own prerequisites.

[maralcbr]

Approving at 5af49598. Thanks @chriskearney for carrying this, and @erykwieliczko for the original work.

• The four carried commits have the same stable patch IDs as d82144ad, 8525dd8e, 610cc54a and 8824dd6a, and keep Eryk's authorship. The production delta from the follow-ups is one rustfmt arm in engine.rs and the ownership comments in job.rs, uat.rs and vm.rs, which fixes the doc nit from my #233 review (failed jobs keep their slot until the last reference drops, and until reboot only after a fail-stop).
• The fixture repairs still extract the production bodies, and the new mutants target real safeguards. The input-error mutants cover binding/completion/prefix admission, retention catches an ignored PMP readiness error and PMP on another platform, and the supplier fixture catches a discarded report error. The zero-words hash change is only the MAX_VMS removal.
• The PMP vote stays T6030-only: pmp-export.c:74-81 gates on the machine, supplier, command and AGX ID, and pmp-report.c:1303-1332 checks them again. Reporting runs only after the backend starts, and a failed power-off tries to restore the report and keeps the original error.

Fine as follow-ups, not blockers:

• At the stamp wrap, encode.rs:490 still sends a literal WAIT = 0 for Stamp barriers. Naeem's J516C run covered a compute-only wrap. TA→FS, FS→compute and mixed wraps with dependent output are still unchecked.
• A job resuming on a different ASID is still untested. The rebind path updates the context and invalidates the changed ASID (mmu.rs:2807-2836), so this is coverage only.
• This lifts the 63-live-VM cap, which is the intended admission change. Queue limits (MAX_QUEUES = 58) still apply, and robust isolation stays single-slot.

This carry binary hasn't been booted. The hardware evidence is still the #233/#238 runs. Once this lands, #233 and #238 can be closed as superseded.

[chriskearney]

@malik-na — source pointers and the proposed M3 Max investigation from the TXT, in an attachment-free form for your agent. This is a follow-up hypothesis to the merged T6030 work, with no new Max performance result claimed.

For Naeem's agent: investigating a possible M3 Max GPU power/bandwidth bottleneck
2026-10-28

The concrete lead

Eryk's M3 Pro fix found that powering the GPU through RTKit was not enough to enable PMP's GPU bandwidth controllers. T6030 also needs the PTD/PMP report asserted after the GPU backend starts. This is a useful hypothesis to investigate on T6031/M3 Max; it is not evidence that the Max has the same fault or will gain the same amount.

The change is merged through #253 and is included in integration merge 30a6518:
#253

Read these exact source paths at 30a6518:

1. drivers/soc/apple/pmp-export.c
   https://github.com/omacom/linux-aurora/blob/30a651868a252e1b737cf5c0597a2157b8ac985c/drivers/soc/apple/pmp-export.c
   apple_pmp_set_device_power() checks report readiness and coordinates the RTKit vote with the report. apple_pmp_t6030_gpu_ready() reasserts the report after backend startup, including recovery from an earlier failure. Failed power-off paths attempt to restore a conservative report state while retaining the original error.

2. drivers/pmdomain/apple/pmp-report.c
   https://github.com/omacom/linux-aurora/blob/30a651868a252e1b737cf5c0597a2157b8ac985c/drivers/pmdomain/apple/pmp-report.c
   apple_pmp_report_t6030_gfx() validates the supplier/table, finds the matching report and checks readiness before changing its state. The AGX request is T6030's ordered device ID 5, report index 4. Admission requires T6030 and apple,t6030-pmp-v2. Those IDs, offsets and supplier assumptions need independent T6031 evidence before any port.

3. drivers/gpu/drm/asahi/g15 backend startup and PMP glue
   Trace the asahi_g15_pmp_ready()/apple_pmp_t6030_gpu_ready() callers. Preserve startup ordering and the readiness/error paths. A GPU already appearing as READY does not by itself prove its bandwidth reporting is correct.

Proposed investigation

Start with a reproducible native-driver baseline: exact kernel/Mesa/Stage2 versions, mapped native libraries, fixed resolution/settings and repeat timings. Compare on the same display/presentation path. Record output correctness and GPU faults alongside speed.

Then distinguish GPU clock, memory bandwidth, CPU submission and presentation limits using existing supported telemetry/profiling. A Max with more GPU cores can still be held back by memory bandwidth or a CPU-side queue. First establish which resource is limiting the workload.

Inspect the existing T6031 power-domain/PMP/report setup and compare its intended bandwidth-vote lifetime with the T6030 sequence. If evidence shows a missing report or vote, implement the SoC-specific equivalent with validated T6031 suppliers, table entries and ordering. Keep the existing firmware/admission checks and error handling. A blind expansion of the T6030 compatibility guard is not a valid port.

If clocks and bandwidth are already correct, investigate shader/compiler scheduling, synchronization and CPU submission overhead. Shared G15 stamp, slot-lifetime and locking changes are already carried in #253; measure the remaining bottleneck rather than duplicating those fixes.

Validate a proposed change with the same repeated workload, native GL/VK output checks, error/fault logs and power-transition behavior. Separate a measured bandwidth improvement from a general GPU speedup. Mixed-workload stamp wrap and different-ASID resume remain separate nonblocking coverage follow-ups from the carry review.

What the existing evidence does and does not show

Our original combined M3 Pro kernel/Mesa test improved the recorded Quake case from 186.5 to 658.7 FPS. Both components changed together; this does not isolate PMP's contribution or predict a Max result. The benchmark method and results are public here:
#238 (review)

Mesa#17's restored conditional rendering, unified layouts, memory-budget reporting and 16 descriptor sets are G15S/M3 Pro-specific. They are feature exposure, not a generic Max performance switch. M3 Air (T8122/G15G) also requires its own diagnosis and verified power-controller interface.

A useful result would identify the limiting resource, the exact T6031 mechanism involved, before/after measurements with driver attribution, correctness/regression evidence, and any remaining uncertainties. No new Max or M3 Air performance measurements are claimed by this brief.