[erikwb]

What this is

On the M5 Max, #1012's driver can run GPU work before the work it waits for has finished:

• Without the G17D forms (the M5 Max), a compute kick's implicit parent is pipelined: the next kick on a ring may start while its predecessor still runs. The M5 Max needs it that way; with the G17D forms' completion parent, its compute kicks never complete.
• Input conversion replaces a compute input's completion wait with ring order. A consumer published behind its producer on the same queue therefore ran alongside it and read memory the producer had not finished writing.
• Leaving other-engine producers to firmware waits also lost devices to submission timeouts under load.

This adds a backend query that holds for an M5 board without the G17D forms. On those boards, compute inputs keep their completion fences, and other-engine prefix producers are waited for on the host, with their errors checked before publication. The M5 Ultra and the other GPUs keep their firmware dependencies; the M5 Ultra passes the same CTS sample without this change.

This fixes the multi-queue synchronization known issue from #1056 (now part of #1012), apart from the MMU faults below.

Testing (J716c, bare metal)

Tested on the previous #1012 head (d078ca1) with #1056 and the GPU device tree, with the same Mesa build throughout. The patch rebased onto this head unchanged. It is rebased again onto #1012's current head (0dd0833), unchanged, and 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).

• Three synchronization2.op.multi_queue cases that returned wrong memory contents on every run: 15/15 passes.

• The 65 synchronization cases (multi-queue, cross-instance, timeline semaphore) that failed or crashed in the drm/asahi: g17: Run the M5 Max (J716c) GPU on bare metal #1056 sample: 195/195 passes over three runs, on two boots.

• A 1-in-100 sample of the Vulkan CTS default list (17073 tests, 8557 not supported):

  	Pass	Fail	Crash	Job timeouts
  Without this change	8345	23	52	17
  With it, three runs	8401 / 8387 / 8387	4 / 14 / 0	38 / 43 / 40	0 / 0 / 0

• Turning off only the input conversion still left 24 and 60 job timeouts in two samples, so both halves are needed.

• Builds with integration's defconfig + asahi.config, with KUnit.

Known issues

GPU MMU faults remain (0, 1 and 5 recoveries in the three samples above). They are being investigated separately.

🤖 Generated with Claude Code

[DjDeveloperr]

Approved. This works on the M5 Pro too, and it fixes a real M5 Pro bug.

host_producer_waits() holds on J714, which has no G17D forms, so this commit changes the M5 Pro's behaviour as well. I compared the same kernel, Mesa (15eb7b7be4) and boot flow with and without it; #1177 was also in the "with" kernel. The commit cherry-picks cleanly onto 0dd0833. Results on J714sAP, bare metal:

	without	with
multi_queue.timeline_semaphore write_copy_buffer_read_ssbo_geometry.buffer_16384_concurrent and write_copy_image_read_blit_image.image_64x64x8_r32_sfloat_exclusive	Fail 3/3 each	Pass 3/3 each
every 20th synchronization2.op.multi_queue.timeline_semaphore case (214)	175 Pass, 34 Fail, 5 DeviceLost	208 Pass, 0 Fail, 6 DeviceLost
dEQP s0 smoke	109 Pass, 2 NotSupported	109 Pass, 2 NotSupported
compute 65,536 words / 256x256 triangle	PASS / crc32 d5e4bea9	same

Every DeviceLost case in both runs is a 128x128 RGBA32F image case in the vertex or tessellation stages. That is the M5 Pro firmware's ~12 ms vertex-phase limit, which this change doesn't affect.

[DjDeveloperr]

Leaving this open: it is based on #1012 (funkzy/t6050-gpu-on-integration) and needs its firmware-27 display/GPU code, and #1012 isn't being merged in this round. It can be retargeted to integration/aurora once #1012 is in.

🤖 Generated with Claude Code

[DjDeveloperr]

Update: I am handling this rebase directly as part of the owner's M5 integration work. The freshly pinned #1070 head is 26d82876dbcf (the earlier form already contained in #1411); it rebases cleanly onto #1406 at d2566e93444f, with unchanged range-diff and Erik Bourget's authorship preserved. The original remote head is retained for rollback. The corrected branch will be published with an exact force-with-lease after the reconciled M5 stack passes its fresh build and hardware gate.