Add a runtime slang-test for the `abort` feature (VK_KHR_shader_abort)

[nv-slang-bot]

Summary

Add a runtime test (via slang-test) that exercises the abort intrinsic shipped in #11542, executing on a Vulkan device that supports the new VK_KHR_shader_abort API.

Requested by @jkwak-work in #11528 (comment).

Background

• Parent feature: Support VK_KHR_shader_abort #11528 — Support VK_KHR_shader_abort (closed/completed).
• Implementing PR: Add abort intrinsic for VK_KHR_shader_abort support #11542 — added void abort<each T>(NativeString format, expand each T args) (overloading the existing SM4 abort()), lowered to kIROp_Abort, emitted as OpAbortKHR (SPIR-V) / abortEXT (GLSL).
• Vulkan proposal cited by the maintainer: https://docs.vulkan.org/features/latest/features/proposals/VK_KHR_shader_abort.html

The feature currently has compile-/emit-side coverage, but no runtime test that actually runs an abort-using shader on a GPU and validates its behaviour. This issue tracks adding that runtime test.

What the test should do

• Compile a Slang shader that calls abort(...) (with a format string + arguments) for a Vulkan/SPIR-V target.
• Run it on a Vulkan device using the new VK_KHR_shader_abort API path, with the shaderAbort feature enabled (VkPhysicalDeviceShaderAbortFeaturesKHR) and the AbortKHR SPIR-V capability declared.
• Validate that the abort actually fires and that the abort message round-trips correctly (e.g. the format string + args reach the host).

Runtime-validation constraint (carried from triage)

Per the Vulkan proposal, abort ceases all further processing in the invocation and causes other invocations to terminate, which triggers device loss. Observing/validating the abort — in particular retrieving the abort message — requires VK_KHR_device_fault (vkGetDeviceFaultDebugInfoKHR() with a chained VkDeviceFaultShaderAbortMessageInfoKHR). Without VK_KHR_device_fault, the abort still causes device loss but the message cannot be retrieved.

Implications for this test:

• It needs a real GPU + Vulkan driver that supports both VK_KHR_shader_abort (with the shaderAbort feature) and VK_KHR_device_fault.
• It is therefore not validatable in the current CI (no GPU; and the two extensions may not be available on available runners).
• The test should be gated on device-feature/extension detection at runtime and skipped where unsupported, and likely needs a dedicated GPU runner (or manual/local execution) until such infra exists. Expect it to run as a GPU-only / opt-in test rather than part of the default CI matrix.

Scope

Runtime slang-test coverage for abort only. The separate emit-side OpExtension token note (Gap C) stays flagged on #11528 and is out of scope here.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jkwak-work]

@nv-slang-bot , please give me a PR for this issue.

[nv-slang-bot]

@jkwak-work — I looked into authoring this runtime test and want to surface a feasibility finding before producing anything, because the runtime path turns out to be blocked on harness/RHI work rather than compiler work.

Short version: the abort compiler side is fully shipped (#11542) and has emit + diagnostics coverage. A runtime slang-test that actually runs an abort() shader on Vulkan and validates the abort fires + the message round-trips is not expressible in the current slang-test / slang-rhi harness — it needs new slang-rhi plumbing first. Details and the choice are below.

Why it isn't authorable today (3 blockers)

Measured against the current pins — slang master (3873af2d) and the slang-rhi submodule pin 687dc18:

1. slang-rhi has no ShaderAbort feature / device-fault retrieval. As of slang-rhi 687dc18, a search of src/ + include/ finds no references to shaderAbort, VK_KHR_device_fault, vkGetDeviceFaultDebugInfoKHR, AbortKHR, or ShaderAbortMessage, and the Feature enum (SLANG_RHI_FEATURES in include/slang-rhi.h) has no ShaderAbort entry. So the Vulkan backend currently has no path to enable VkPhysicalDeviceShaderAbortFeaturesKHR::shaderAbort or request VK_KHR_shader_abort / VK_KHR_device_fault.
2. Nothing to gate the test on, and no way to read the message back. slang-test gates runtime tests with -render-features <name>, which render-test maps to an rhi::Feature and skips (returns SLANG_E_NOT_AVAILABLE) when the device lacks it (tools/render-test/render-test-main.cpp, _getFeatureFromName + the required-feature check). With no ShaderAbort feature there's no name to gate on, and there's no vkGetDeviceFaultDebugInfoKHR / VkDeviceFaultShaderAbortMessageInfoKHR path to retrieve the abort message.
3. Device loss is incompatible with the execution model. The runtime directives (COMPARE_COMPUTE / EXECUTE) dispatch, then read back an output buffer and compare. Per the VK_KHR_shader_abort proposal (and the intrinsic's own doc at source/slang/hlsl.meta.slang), abort causes device loss — so even on hardware that supported the extension, today's harness would report a hard device-lost failure on readback, not a validated abort. There's no slang-test directive that expresses the device-fault-retrieval validation this test requires.

For reference, the shipped intrinsic is [require(abort)] __intrinsic_op($(kIROp_Abort)) void abort<each T>(NativeString format, expand each T args) (source/slang/hlsl.meta.slang), with existing compile/emit coverage in tests/spirv/abort*.slang and tests/diagnostics/abort-*.slang. The gap is purely the runtime/RHI side.

Prerequisite work (all in shader-slang/slang-rhi)

1. Add a ShaderAbort entry to the slang-rhi Feature enum + detect/enable VkPhysicalDeviceShaderAbortFeaturesKHR::shaderAbort and request VK_KHR_shader_abort (src/vulkan/vk-device.cpp).
2. Add VK_KHR_device_fault support + an API to call vkGetDeviceFaultDebugInfoKHR and surface the chained VkDeviceFaultShaderAbortMessageInfoKHR message to the host.
3. Add a render-test execution mode that tolerates device loss after an abort dispatch and exposes the retrieved message for validation (the readback-compare path can't be reused).
4. Then the slang-test is straightforward: gated on the new shader-abort render-feature so it skips via SLANG_E_NOT_AVAILABLE where unsupported. It would still need a GPU runner that supports both VK_KHR_shader_abort and VK_KHR_device_fault — not present in current CI.

Net: this issue is effectively gated on slang-rhi prerequisite work, so it may warrant a tracking issue in shader-slang/slang-rhi — I'll leave filing that to you since you own that repo.

Your call

Since you own slang-rhi, the next step is really your decision:

• (B) Scaffold PR now — I can open a draft PR with the abort compute shader + the intended runtime directive (disabled, pending the RHI work) + this roadmap in the body, clearly marked blocked / GPU-only / not validatable today. Honest about what it can't do, but it can't actually run until the prerequisites land.
• (C) RHI prerequisites first — land the slang-rhi feature + device-fault + device-loss-tolerant render-test mode, after which I (or anyone) can add the gated runtime test cleanly.

Happy to produce (B) if you'd like the scaffold, or to pick up the gated test once (C) is in place — just let me know which you'd prefer. I have not opened a PR or closed this issue.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jkwak-work]

@nv-slang-bot , please create a new issue on shader-slang/slang-rhi repo about the required task.
I will come back to this issue when the slang-rhi side work is completed.

[nv-slang-bot]

Per @jkwak-work's direction above, I've filed the slang-rhi-side prerequisite as shader-slang/slang-rhi#781, describing the RHI work needed before this runtime test is authorable: enabling VK_KHR_shader_abort + the shaderAbort feature, VK_KHR_device_fault message retrieval (vkGetDeviceFaultDebugInfoKHR + VkDeviceFaultShaderAbortMessageInfoKHR), a Feature enum entry for runtime detection/gating, and host-side abort-message + device-loss handling.

Parking this issue pending the slang-rhi-side work (per jkwak's note that he'll return here once that completes). Keeping #11790 open as the tracking item for the dependent runtime test. The Slang compiler side is already shipped (#11542); the remaining gap is purely the runtime/RHI path tracked in the slang-rhi issue above.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jkwak-work]

@nv-slang-bot
The PR on slang-rhi repo looks good to me:

• Vulkan: support VK_KHR_shader_abort + VK_KHR_device_fault slang-rhi#782

Can you make a slang PR after cherry-picking the submodule commit and adding some slang-test test cases with it?
I want to see if the slang-rhi PR actual works with slang-test.

[nv-slang-bot]

Thanks @jkwak-work — opened the slang integration PR: #11792.

It bumps the external/slang-rhi submodule to #782's head (dfd2e66, branch fix/issue-781) and adds a gated runtime test tests/spirv/abort-runtime.slang: a SIMPLE SPIR-V emit check (OpAbortKHR) plus a -vk COMPARE_COMPUTE line gated on -render-features shader-abort (which maps to rhi::Feature::ShaderAbort automatically via SLANG_RHI_FEATURES, so no render-test change was needed).

Verified locally (GPU-less Linux): slang builds against the bumped submodule — slang-rhi's new VK_KHR_shader_abort code compiles against the v1.4.347 Vulkan-Headers it self-fetches (bumping the pin alone is enough; slang's own external/vulkan isn't used by slang-rhi's VK backend) — the test is discovered, the emit line passes, the -vk line skips cleanly, and the existing tests/spirv/abort*.slang emit tests still pass.

Not verified here or in CI (no capable hardware): the abort actually firing, the device-fault path, and the message round-trip via vkGetDeviceFaultDebugInfoKHR. Those need a device with both VK_KHR_shader_abort and VK_KHR_device_fault — that's the part for you to run on a capable device, which is the point of this PR. The abort() call sits on a branch the dispatch never reaches, so it exercises the abort-capable pipeline without losing the device.

It's intentionally a draft and can't merge until #782 lands and the submodule pin moves to a merged slang-rhi main SHA.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}