[jgoyvaerts]

Makes partial renders work on the M4 Pro's 25G83 firmware, so a pass that overflows the tiler heap finishes instead of losing the GPU. Today every pass asks the firmware to grow the heap, and a pass that hits the 3353-block maximum fails with reason 0. Counter-Strike 2's soundpack preview is one: a depth pre-pass at 3456x2234 grows to the maximum and the client gets DEVICE_LOST.

macOS sets TA+0x892 only for memoryless passes. An ordinary pass stops, flushes a partial render when the heap runs out, and the heap grows between renders. Turning that on was not enough: partial renders hung or produced wrong pixels on 25G83. The first five patches fix what was found, and the last one turns it on, so no commit in the series enables a broken path.

1. Tiler segment limits. 0x1c890, 0x1c918 and 0x1c9a8 were 0. Without 0x1c9a8 the pages a pass returns shrink to none and the tiler spins.
2. Render pool, 22 to 44 MiB. This was the hang: a stopped tiler's threads keep their USC private memory and the fragment pass starves.
3. gtp6 size. 0x600 is smaller than macOS's 0x1c00. It is now sized for the largest pool, which is what every test ran with.
4. Depth and stencil control words. The macOS rule, with each pass's own loads kept in the first segment. A loading pass that did real work there stored background depth over the real values. This was CS2's black tiles.
5. Last segment walks every tile. Without it, a tile only earlier segments drew to is never resolved by an in-tile resolve.
6. Partial-render ordinary passes, on 25G83 only.

The register values come from DTrace captures of macOS on the same machine and firmware. The array word 0x80045 / 0x88045 was captured on a pass that clears depth, so keeping a loading pass's loads is inferred, and shown by the results below.

Scope. V26A428 keeps the grow request, so it shouldn't reach the arrays patches 4 and 5 change. The pool size is a shared constant, so A18 Pro pays the extra 22 MiB per context too. Patches 1 and 3 and the last patch apply to V25G83 only. The segment control value is the macOS two-cluster value, so #525 would need to check it for T6041.

Testing, M4 Pro (J616s, T6040), firmware 25G83

• CS2, soundpack preview: no crash, 0 GPU recoveries. Before patch 4, up to 2,937 of 5,400 tiles were black. After it there were none in 48 captures across 2 soundpacks, including about 90 s watching for flicker, with the depth pass still overflowing twice a frame. Also checked by hand at 4x MSAA and in game.
• Pixels: a Vulkan client compared byte for byte against the same scene split into passes that can't overflow, at both the starting pool and the grown pool: depth then colour at EQUAL, 1x and 2x, D32 and D32S8, stencil tested, depth loaded from a non-clear value, discard, per-draw state, occlusion queries, two colour targets, 1 to 4 stops, concentrated and spread geometry. All identical. Depth then colour at EQUAL on the grown pool was 100% wrong before patch 4. The in-tile resolve scenes differ only by resolve rounding, at most 1 level.
• dEQP-VK renderpasses, 1/40 slice, 8 jobs: 1,201 Pass, 844 Skip, 0 Fail, the same as before the series.
• Stress: 3M triangles 12 of 12 at 179 ms, 9M 527 ms, 20M 1,172 ms, far past the old maximum. 1,257 of 1,257 process restarts in 5 minutes at 3M on an earlier kernel of the series. 0 recoveries.
• Speed: scenes that overflow only on their first frame are unchanged, within noise.

Not tested: A18 Pro, T6041, and frame rate in scenes that overflow every frame beyond CS2's preview.

Known issues

• Each 4x render that overflows differs from the last in about 0.02% of pixels, with or without the stored samples, and 0.8% from a reference. No whole tile is lost. The cause is unknown, and it doesn't happen at 2x or without an overflow.
• The pool costs lower-window space. 44 is measured, not derived: 22 lost every run, 27 passed. Refused allocations in the dEQP slice went from 0 to 15, all retried, no failures.
• Linux has no memoryless flag, so such a pass would partial-render too. Honeykrisp always backs its attachments. GL clients were not checked.
• In a pass with a smaller render area, loadOp DONT_CARE and an in-tile resolve, a tile entirely outside the area reloads undefined samples and resolves them over the destination. It takes an overflow as well. Layered passes with the same load op were not tested.

Tested tree. The tests ran on 9ff2b9a3761d plus our carried patches. aurora-wip has had no driver, UAPI or rust/kernel change since. Of the carried patches, four touch the driver: #837, client names in failure reports, MMU fault banks in the recovery log, and the asahi driver name. None touches this path. Patches here were reordered for this PR, and their combined driver diff is the same as the tested one except for the V25G83 condition in the last patch, which keeps the same value on 25G83. Every commit compiles.

[RyanTheTide]

Merged. I added one fixup on top (3afdeac, Ryan): the three tiler constants sat between ta_registers_25g83()'s doc comment and the function, so rustdoc gave the function's description to VDM_SEGMENT_CONTROL. That commit only moves the constants above the comment.

Tested on the J616s as a one-shot of 7.3.0-aurora-m4t1103a (integration/aurora 19f71a1 + #837 + this series with the fixup + #884), boot c9c549d5. The tree is the same as the merged one:

• Kernel -p3 is empty. SELinux is enforcing with 0 AVCs, and the warning set is the same as fleet14p's.
• Mesa CTS, 21,405 cases on that boot: 19,899 targets (draw, renderpass(es), multisample, depth, glsl, texture, binding_model, robustness2 and more) plus 1,506 stride controls, at 4 jobs on the tip Mesa and two test merges. 0 Pass lost against tip, 0 Fail, 0 GPU recoveries.
• It also fixes the M4 Pro hang from mesa#109. A synthetic client with 109's frame shape (3 depth-only passes + 4 2x MSAA passes per frame, 3 in flight, stock tip Mesa, no serialization):
  • on fleet14p: hung at frame 691,863 (recovery reason 0, the tiling side of the stuck render done, its fragment side not)
  • on this series: 1,500,000 frames with 0 hangs, at 1340 fps against 1207 before

Not run: the A18 Pro. It pays the larger render pool and keeps the grow request. A Neo one-shot is next, once the Neo is back from a reinstall.