Repository navigation
drm/asahi: Lay out the M5 Max render context store for four clusters - #1177
Conversation
DjDeveloperr
left a comment
DjDeveloperr
left a comment
There was a problem hiding this comment.
Approved: no change on the M5 Pro, and no regression there.
J714 has clusters: 2, so ContextStore::selected still picks of(2) on it; only the four-cluster J716C moves to its physical count. The new compile-time assertions hold in a build on 0dd0833. The Max values match of(4): extent = stream 0xfc0 + 4 × 0x680 + 0x800 = 0x31c0.
On J714sAP with this commit (and #1070): the triangle still gives crc32 d5e4bea9, compute passes, and the s0 smoke set is 109/0. The multi-queue sample is in #1070's review.
|
Leaving this open: it is based on #1012 ( 🤖 Generated with Claude Code |
J716C has four clusters, but ContextStore::selected used the two-cluster layout unless the board selected G17D forms. Select the physical cluster count for four-cluster boards as well. This changes the auxiliary and state-stream offsets and the host viewport location; the rounded backing allocation stays the same size. Add compile-time checks for the Max's selected offsets and the surrounding per-render storage layout. On M5 Max with identical Mesa, six full 17,073-case samples across two boots had no recoveries, timeouts, crashes or flakes. Reverting to the two-cluster layout reproduced an MMU recovery in the first full sample. All six 848-case synchronization rounds on the four-cluster build passed. Developed with Claude Code. Signed-off-by: Erik Bourget <erik@ebourget.net>
a520e8c to
eb051de
Compare
J716C has four GPU clusters, but
ContextStore::selectedchose the two-cluster render context-store layout. Select the physical cluster count for the four-cluster Max, as the G17D path already does. This updates the auxiliary and state-stream offsets and the host viewport location; the rounded backing allocation remains 64 KiB. Add compile-time assertions for the selected Max layout and its enclosing storage.Based on #1012, which now carries #1056's J716c commits. This PR contains only the context-store change; the queue admission, compute ordering and Mesa lifetime/sharing changes used in testing are separate.
Validation on M5 Max, using identical Mesa and case lists for the layout comparison:
stats.sh.The 23 stable failures (22 sparse cases and one layered-geometry case) remain and reproduce without GPU recovery. The precise mechanism by which the old layout fails under mixed load is not established; the old native Max driver also selected two clusters. Hardware validation used #1070, separate kernel admission fixes, and the Mesa lifetime/admission/sharing fixes in addition to #1056, held constant across the layout comparison.
Rebased onto #1012's current head, unchanged. It runs in the J716c daily on current integration/aurora, which passes an 18,427-case sample of the Vulkan default list (9,694 passes; only the two driver-ID/conformance metadata failures; no GPU recoveries).