Make Fp16x2 atomics its own capability.

[csyonghe]

Problem Description

Right now InterlockedAddF16 maps directly to single fp16 atomic add in SPIRV, which is supported by some vendors but not by NVIDIA. On NVIDIA, the user needs to call InterlockedAddF16Emulated instead that uses a fp16x2 atomic under the hood.

This means that a user writing cross platform/vendor code almost always need to call InterlockedAddFP16Emulated, which could mean slower execution on non NVIDIA hardware.

Preferred Solution

Make Fp16x2 atomics its own capability, separate from fp16 atomics, so the implementation of InterlockedAddFP16 can target_switch on the availability of the capabilities, and fallback to emulation when fp16 atomics is not available. This allows the user to select which code path to use from the -capability compiler option.

[nv-slang-bot]

Triage

Category: Feature / refactor (improving cross-platform ergonomics).

The current state at master:

• InterlockedAddF16 is at source/slang/hlsl.meta.slang:6359 and requires [require(cuda_hlsl_spirv, sm_5_0)]. The default (SPIR-V) path emits OpAtomicFAdd on a half via __atomic_add — i.e., native single-element fp16 atomic (capability spvAtomicFloat16AddEXT from SPV_EXT_shader_atomic_float16_add, defined at slang-capabilities.capdef:544,701).
• InterlockedAddF16Emulated (line 6399) does the fp16x2-based emulation — uses NV's _NvInterlockedAddFp16x2 on HLSL or maps to a fp16x2 atomic on SPIR-V (capability atomic_glsl_halfvec → GL_NV_shader_atomic_fp16_vector, defined at :1017,1264).

Proposed change: split capability requirements so InterlockedAddF16 itself is the single user-facing entry point and __target_switch-es on capability availability:

• if the single-element fp16 atomic capability is available → emit native fp16 atomic
• otherwise, if the fp16x2 atomic capability is available → emit the emulated fp16x2 path
• otherwise → diagnostic (or fall through to a slower CAS-loop fallback if one exists)

The two SPIR-V capabilities already exist independently (spvAtomicFloat16AddEXT vs _GL_NV_shader_atomic_fp16_vector), so the underlying capability machinery is in place. The work is concentrated in:

• source/slang/hlsl.meta.slang:6359 — rewrite InterlockedAddF16 body to dispatch on which atomic capability the target satisfies
• Possibly source/slang/hlsl.meta.slang:6399 — deprecate InterlockedAddF16Emulated once InterlockedAddF16 handles the fallback automatically (or keep both but document the redundancy)
• A test under tests/ exercising both target paths under different -capability settings

Note that on HLSL the default path already routes through NVAPI (_NvInterlockedAddFp16x2) regardless — the capability dispatch matters mostly for SPIR-V/Vulkan and CUDA. For HLSL the fallback is essentially "is NVAPI available", not a Slang-level capability.

Severity: low — purely an ergonomics improvement; existing API still works.
Labels: spirv_vulkan (already), keeping Dev Opened + RTR.

[nv-slang-bot]

Took a pass at the proposed dispatch and ran into the capability-system rules — escalating with what I tried and where it blocks.

What I tried

Per the triage proposal: keep InterlockedAddF16 as the user-facing entry, dispatch via __target_switch on a capability case.

1. Added alias atomic_glsl_halfscalar = spvAtomicFloat16AddEXT; in source/slang/slang-capabilities.capdef, mirroring the existing atomic_glsl_halfvec.
2. Replaced [require(cuda_hlsl_spirv, sm_5_0)] on InterlockedAddF16 with three [require] lines:

   [require(cuda_hlsl, sm_5_0)]
   [require(spirv, spvAtomicFloat16AddEXT)]
   [require(spirv, /* halfvec capability */)]
   

3. Added case spvAtomicFloat16AddEXT: (native single-element fp16 atomic body) and case _GL_NV_shader_atomic_fp16_vector: (fp16x2 emulation body, copied from InterlockedAddF16Emulated) to the body's __target_switch. Pattern modelled on the existing _GL_NV_shader_invocation_reorder cases at source/slang/hlsl.meta.slang:22144+.

Where it blocks

• __target_switch case only accepts def-defined capability names, not aliases (error[E36109]: invalid target_switch case).
• [require(...)] rejects _Internal-marked defs — error[E36111]: disallowed capability ... resolves into a disallowed Invalid Capability. So I can't put _GL_NV_shader_atomic_fp16_vector directly in a [require].
• The public alias GL_NV_shader_atomic_fp16_vector is defined as _GL_NV_shader_atomic_fp16_vector + _GL_NV_gpu_shader5 | _spirv_1_0 (slang-capabilities.capdef:1264). The trailing | _spirv_1_0 makes it satisfiable by any SPIR-V 1.0+, so [require(spirv, GL_NV_shader_atomic_fp16_vector)] doesn't actually gate on the halfvec extension — it's effectively "any spirv". atomic_glsl_halfvec aliases the same broad set.
• Net: the resolved [require] for InterlockedAddF16 came out as (sm_5_0 || cuda_sm_6_0 || spvAtomicFloat16AddEXT) — no halfvec branch — and the case _GL_NV_shader_atomic_fp16_vector: body failed conflict-checking (error[E36101]: ... requires capability ... that is conflicting with the [require]'s ...).

The closest working precedent is the ser family used for the _GL_NV_shader_invocation_reorder cases, but ser's alias chain happens to thread the internal cap through a strict-enough public alias for [require] to accept. The fp16-vector chain doesn't have that — GL_NV_shader_atomic_fp16_vector | _spirv_1_0 is too permissive.

What's needed

A tighter public alias, e.g. something like

alias GL_NV_shader_atomic_fp16_vector_strict = _GL_NV_shader_atomic_fp16_vector + _GL_NV_gpu_shader5;

(without the | _spirv_1_0 alternative) that's accepted by both [require] and __target_switch case — analogous to how ser_raygen_closesthit_miss is structured. That's a capdef restructure rather than a meta.slang-only edit, and worth the touch from a capability-system owner.

cc @csyonghe @jhelferty-nv — the proposed dispatch is implementable once the alias situation is sorted; happy to retry once there's a green-lit path. Reverted my partial attempt.

Narrow alternative

If the deeper restructure isn't in scope right now, the safer narrow change would be a docstring clarification on InterlockedAddF16 pointing NVIDIA users at InterlockedAddF16Emulated, leaving the actual dispatch for a later PR. Let me know which you'd prefer.