[sithglan]

Base: integration/aurora (064054d). Four commits, all in drivers/gpu/drm/asahi/m5/.

The M5 backend's reference-render admission admits only the single-sample
profile the first captures covered. On the J813 that refuses submits Mesa
emits every day, and every refusal is a dropped render: the full GLES3 and
GLES31 CTS on the merged stack fail 67 and 72 cases with ENOTSUPP
(errno 524), every one of them from this admission. The same Mesa passes
all of them on the bring-up kernel, whose local admission patches are not
part of the merged line.

This series ports those admissions onto the current upstream code, plus
the depth-size correction the rewritten validation needed:

1. drm/asahi: m5: admit sampler heaps. translate already range-checks
   a sampler heap and the descriptor carries it (+0x87a/+0x882/+0x886 as
   on G17P), so stop refusing every draw whose samplers go past the
   immediate range.
2. drm/asahi: m5: admit occlusion queries. The visibility buffer is
   range-checked, written to 0x15311 and carried in the descriptor;
   Apple's visibility renders move only the ISP control and query-index
   words beside it (25G76 captures, statedump.m occl=1/2). Drop the
   occlusion_query_base refusal.
3. drm/asahi: m5: program the multisample ISP allocation from sample_size. Pass samples/sample_size into the G17p parameters,
   derive the ISP sample control at +0x10051 and +0x1f38 from the sample
   stride instead of a fixed samples << 16, put the imageblock bytes per
   sample at +0x1fac, and size the TA's TPC geometry (+0x788) from the
   unrounded layout. Admit the 32x32 two-sample and 32x16 four-sample
   layouts Mesa submits.
4. drm/asahi: m5: size the depth plane by AIL's sample-scaled element.
   AIL folds the sample count into the data plane's element size (a 2x
   Z16 surface tiles as 4-byte elements over the pixel dimensions) and
   uses the expanded surface only for compression metadata. The rewrite
   expanded the data plane too, so a 119x131 two-sample Depth16 FBO
   (layer stride 0x18000) was range-checked as 0x20000 and rejected.

Testing

J813 (M5, T8142, 8 GPU cores), 7.3.0-aurora-j813-rb+, Mesa 26.3.0-devel
git-3d7e4883c9, VK-GL-CTS mustpass from the same tree.

Before (merged stack, kernel #11):

suite	Pass	Fail	failing cases
gles2	16,956	0
gles3	44,342	67	64 occlusion_query, 3 fbo.msaa
gles31	37,280	72	all fbo.no_attachments

Every failure was DRM_IOCTL_ASAHI_SUBMIT render failed: Unknown error 524
and a M5 render admission rejected line in dmesg.

After (this series; only aurora.ko changed, the Image is the same):

suite	Pass	Fail	Skip
gles2	16,956	0	206
gles3	44,409	0	385
gles31	37,352	0	449

The gles2 count matches the pre-regression baseline exactly, and gles31
returns to its 37,352-pass baseline. A standalone spot check of the three
fbo.msaa cases, occlusion_query.scissor/all_occluders and
fbo.no_attachments.npot_size.127x127/multisample.samples4 passes with
zero M5 render admission rejected and M5 depth admission rejected
lines; the full run logs none either. The gles31 serial re-run still
panics in deqp-runner 0.24.0 (exit 101), so only the parallel pass is
recorded; that predates this series.

Rebased onto integration/aurora: the four commits apply unchanged (git range-diff shows all
four as =). drivers/gpu/drm/asahi/m5/ in integration/aurora 064054d is the same as
in the aurora-wip base these results were measured on, so the results above carry over. The
branch builds with the J813 config (Image.gz, modules, dtbs), and so does each of the four
commits on its own. I could not re-run the CTS on integration itself: the J813 now runs the
macOS 27.0 firmware, where the M5 GPU goes through #1413's g17 runtime, not m5/.

Limits

Still the reference first-job ABI: one hardware command per submission,
one layer, no timestamps, and renders outside the admitted state are
refused with ENOTSUPP. The four-sample limit stands: Mesa still
refuses 4x renders larger than 16 tiles, and the admission keeps the
32x16 utile for them.

/cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10

[RyanTheTide]

This branch is based on aurora-wip. Against integration/aurora it carries 19 commits besides the four drm/asahi: m5: ones: J813 audio, AOP, rtkit, admac and tas2764/cs42l84 changes. Two of those (ad4910c "ASoC: apple: validate J813 audio topology..." and 12165bc "ASoC: apple: initialize J813 output standby...") have no Signed-off-by:.

The four m5 commits apply cleanly on the current integration/aurora by themselves. Could you rebase just those four onto integration/aurora and retarget the PR there? The diff would then be the five m5 files only.

[sithglan]

Done: the four drm/asahi: m5: commits are now on integration/aurora (064054d) by
themselves, and the PR targets integration/aurora. They applied without changes, and m5/ is
the same there as in the aurora-wip base I tested on, so the CTS numbers in the description
still hold. Each of the four builds on its own with the J813 config.

The J813 audio, AOP, rtkit, admac and codec commits are no longer part of this PR. Their port
to integration/aurora is #1423. It does not carry ad4910c and 12165bc, which have no
Signed-off-by.

[DjDeveloperr]

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

No blocking findings in the bounded legacy M5 submit admission. Multisample/occlusion/sampler-heap fields retain range/reserved-bit checks and VM/packet validation. This does not enable the separate FW27 G17 path. Contributor reports identical rebased backend code with J81325G76 GLES CTS evidence and per-commit builds; host CI is green. Those are attributed hardware/build results, not new tests by this review.