[jgoyvaerts]

Accepts ray traversal on the M4 Pro's 25G83 firmware, so Mesa exposes VK_KHR_ray_query and VK_KHR_ray_tracing_pipeline there. It is one switch: ray_traversal in V25G83, which command.rs and RENDER_RAY_QUERY in mod.rs read. The comment beside it goes with it, because the wedge it describes does not reproduce. V26A428 has no comment on this field either.

Mesa needs aurora-silicon/mesa#139 for a clean CTS run. Without it 5 cases fail, and procedural spheres render inside out. The two PRs can land in either order.

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

• CTS: ray-query, ray-tracing-pipeline and the acceleration structure cases of binding-model and api, 74,833 cases: 49,711 Pass, 25,122 NotSupported, 0 Fail, 0 GPU recoveries, in about 10 minutes at 8 jobs with no reboot, with everything that did not pass there run again alone. About 90% of the NotSupported cases are opacity micromaps.
• Forced stall: a built BLAS overwritten with a cycle of the driver's one-child node. The firmware recovered with reason 0 at 1.76 s (compute) and 0.12 s (fragment), with no MMU fault. Plain compute and render worked after both, and ray tracing worked after the compute one. I could not tell whether the hardware looped or rejected the back-reference.
• Long but valid traversal: thin triangles whose boxes all hold the ray while none touches it, so every leaf must be visited, in front of a wall that proves the traversal finished. There were 0 firmware recoveries, and every traversal that finished committed the wall at the right distance.

Stage	One ray	Many rays of about 0.9 s each
compute	31.3 s	8,192 rays, 26.7 s job
fragment	14.4 s	16,384 rays, 5 s job

• Real application: a Vulkan ray tracing demo with 16.8 M instanced triangles, a TLAS rebuilt every frame, shadows, reflections, an intersection shader and an any-hit shader, for 1,337 frames at about 53 fps with 0 recoveries.
• x86: ray query is correct on the x86_64 Mesa driver under FEX in 4K page mode.

Limits that stay

• A compute job stops at 38.9 s with ETIMEDOUT, which is timeout.rs: 2 s * (1 + 4 execution + 14 shared renewals). Only that client fails. By the code an otherwise idle GPU gives 10 s; I did not measure that.
• All render work waits behind a fragment job, so a long fragment traversal freezes the desktop. A 14 s one passed. At 28 s the job failed with ETIMEDOUT and so did what waited behind it: Hyprland lost its device after about 24 s and the session had to be rebooted. Ordinary frames take milliseconds, so this takes one render that runs for many seconds. The extra allowance for ray work is what makes it reachable.
• A recovery can fail a running render of another client, as with any GPU hang: the fragment stall failed a t3code render with ECANCELED. That run had drm/asahi: g17: keep innocent clients alive across another client's recovery #803 applied, and drm/asahi: g17: keep innocent clients alive across another client's recovery #803 leaves work the firmware lists as interrupted failing.
• 8 parallel deqp-vk jobs hit capacity refusals (LowerVa, and with games open also LogicalQueues and ComputeReserve). Every affected case passes alone. Those refusals happen without traversal too.

What this was tested on
Not stock aurora-wip. The kernels were 52f0a6bee plus our carried patches, with our J616s device tree. drivers/gpu/drm/asahi, the DRM UAPI and rust/kernel are unchanged between 52f0a6bee and this base. On the driver our tree carries: client names in failure reports, #803 with the ENODATA fix, MMU fault banks in the recovery log, and the asahi driver name. None of them touches ray traversal. The sweep and the stalls ran with an equivalent test parameter on m4.101, the long traversal and the application with this change on m4.102.

[RyanTheTide]

Hardware evidence from tonight. The merge itself waits for this PR to be retargeted to integration/aurora, which is with Ryan.

J616s (M4 Pro, 25G83) one-shot of 7.3.0-aurora-prr1103c = integration/aurora f153499 + this PR + #790 + #731, boot 6a127964:

• VK_KHR_ray_query and VK_KHR_ray_tracing_pipeline are exposed on both the installed Mesa (c208afc) and the G17P test merge that includes mesa PR 139.
• A CTS sample on that boot, at jobs=4 under the guarded launcher: 4,813 ray_query cases (every 8th) and 170 ray_tracing_pipeline.misc/ser cases. 4,197 + 126 Pass and the rest NotSupported, the same on both drivers, with no Fail, Crash or GPU recovery. The 5 cases that 139 fixes aren't in the 1.4.6.2 caselist used here.
• The boot is k -p3 0 with 0 AVCs, and its warning set is identical to fleet14p's. The machine is back on fleet14p.

[RyanTheTide]

Merged after a J616s one-shot of 7.3.0-aurora-m4t1103a (integration/aurora 19f71a1 + this PR + #879 + #884), boot c9c549d5:

• VK_KHR_ray_query and VK_KHR_ray_tracing_pipeline are exposed.
• Kernel -p3 is empty, SELinux is enforcing with 0 AVCs, and the warning set is the same as fleet14p's.
• A Mesa CTS A/B of 21,405 cases on that boot gave 0 GPU recoveries.
• 1.5M frames of a synthetic depth + 2x MSAA load gave 0 recoveries.

The result from last night's prr1103c boot still holds. The base moved only by #877, #865 and #867, none of which touch drivers/gpu/drm/asahi.