Only request hlsl_nvapi capability where the NVAPI Slang module is linked

[nv-slang-bot]

SlangSession::create_session requested the hlsl_nvapi Slang capability unconditionally, while the sgl NVAPI Slang module that provides it is created and linked only under SGL_HAS_NVAPI && DeviceType::d3d12. The capability request was therefore strictly broader than the module backing it.

Slang 2026.12 (the currently pinned version) tolerates the mismatch silently. shader-slang/slang#11225 rejects it:

error[E36121]: requested capability 'hlsl_nvapi' is incompatible with compilation target 'spirv'

This is a latent SlangPy bug that #11225 surfaced — #11225 itself needs no change.

The fix

Gate the request on the predicate already used at the module-create (shader.cpp:250) and module-link (:659) sites, so the guards cannot drift apart. SGL_ENABLE_NVAPI — the compiler define consumed by nvapi.slang — is already gated on that same predicate in this function.

Both halves of the predicate are load-bearing. Note the evidence for each differs, and neither comes from the local A/B (which short-circuits — see Caveats):

job	SGL_HAS_NVAPI	d3d12 subcases	vulkan subcases
linux-gcc	OFF — module never created/linked	not in the device matrix	FAIL
windows-msvc	ON — module created/linked for d3d12	no observed d3d12 failure	FAIL

The device clause is required because SGL_HAS_NVAPI alone is insufficient: the Windows job has it ON and still fails on vulkan. The availability clause is required for consistency with the module create (:250) and link (:659) sites — where SGL_HAS_NVAPI is OFF the module is never built, so the capability has nothing behind it on any device.

Why one site is sufficient

Re-derived from the raw job logs of run 30779697035:

• hlsl_nvapi is the only capability named in any E36121 — 56 occurrences total, 28 per job — and spirv the only target. No other capability, no other target format.
• All 28 failing cases per job are vulkan, on both platforms. Each failure prints a DEEPEST SUBCASE STACK REACHED block whose following lines name the subcase; enumerating those tokens across both logs (after stripping the Windows log's CRLF line endings) gives vulkan 28× and d3d12 0× per job.
• Assertions 15593/15593 (linux) and 18535/18535 (windows) — 0 failed — against 28 failed cases per job, the signature of module-load failure rather than logic error. Windows reports ~3k more assertions than linux while running {d3d12, vulkan} against linux's {vulkan} (tests/sgl/testing.cpp:73), which is consistent with d3d12 subcases executing but does not independently prove it — platform-specific assertions could also account for the difference.

Had a second capability appeared, a broader audit of capability passing would have been required instead. It does not, so this is the single fix site — confirmed by the A/B below.

Verification

Against the pinned Slang 2026.12 — no NVAPI or shader-session regression observed on the change branch. Built linux-gcc with SGL_HAS_NVAPI: OFF, SGL_HAS_D3D12: OFF, SGL_HAS_VULKAN: ON; unit-test-cpp 195/200 with assertions 15529/15529, 0 failed, and zero nvapi errors. pytest slangpy/tests/device/test_shader_cursor.py test_shader.py: 18 passed. The harness instantiated real vulkan and cuda devices (adapter NVIDIA L40S), so the run was not GPU-skipped — this is not a claim that CUDA-target behaviour was verified. pre-commit run --all-files exits 0 with no hook failures.

The 5 failing cases (dds_file/*, texture_loader_stream_*) are asset-loading failures: the 22 .dds files under data/test_images/ are Git LFS pointer files (file reports ASCII text; contents begin version https://git-lfs.github.com/spec/v1) whose payloads were not materialized in this container. They are apparently unrelated to shader sessions, but the base commit was not built, so their baseline status was not verified.

Because the pin predates #11225, this run shows only that the change introduces no observable regression on the tested paths; it does not reproduce E36121.

Against affected Slang (slang#11225) — verified. Built Slang from source at pull/11225/head (v2026.14.1-24-gdb61cec) and rebuilt slangpy against it via SGL_LOCAL_SLANG=ON, the mechanism CI uses.

arm	failures	E36121
without the guard (upstream main behaviour)	33	28
with the guard	5	0
delta	28	28

The 28 recovered cases equal the 28 E36121 occurrences exactly; all 28 are the identical hlsl_nvapi/spirv pair, matching CI's 28-per-job. 33 = 28 + 5, the 5 being the LFS asset failures above. Nothing else differed between arms.

Three slangc arms isolate the cause more sharply than the integration run can:

command	result
slangc -target spirv -capability hlsl_nvapi	❌ error[E36121] ... 'hlsl_nvapi' ... target 'spirv'
slangc -target spirv	✅ compiles
slangc -target dxil -profile sm_6_6 -capability hlsl_nvapi	✅ compiles

So the capability request is the cause, suppressing it on non-DXIL targets fixes it, and it remains valid for the DXIL target the guard still requests it for.

A positive control ran before either arm: strings … | grep -c 'is incompatible with compilation target' gives 2 for the source build and 0 for the slang-2026.14.1-linux-x86_64 release artifact that the build downloads for slang-llvm. Testing against the latter would have returned clean on both arms — and the trap is self-concealing, since 2026.14.1 is newer than the pinned 2026.12 yet predates the unmerged #11225. Version-newer is not change-inclusive when the change is unmerged.

Caveats, stated explicitly

• Verified at the compile-target level; not at the device level. SGL_HAS_D3D12: OFF here, so the guard's true branch never executed through SlangSession::create_session. E36121 is raised by TargetRequest::checkCapabilities() keyed on the target, with no device term, which is why the dxil + hlsl_nvapi arm above validates the pairing the true branch depends on. Still unverified: d3d12 device creation, runtime NVAPI linkage, and Windows d3d12 subcase execution — D3D12 CI on this PR is what would establish those.

• What the A/B validates is the mechanism, not the choice of predicate. src/sgl/CMakeLists.txt:392 emits SGL_HAS_NVAPI as a literal 0/1, and it is 0 on this host — so the guard short-circuits at the first clause and the device_type comparison is never evaluated. On Linux the patch is therefore behaviourally identical to deleting the capability request outright, or to guarding on SGL_HAS_NVAPI alone. The arm establishes that not requesting hlsl_nvapi is what fixes the SPIR-V failures — the causal claim — while the specific predicate is justified by matching the three existing NVAPI guard sites (:250, :508, :659) plus the Windows CI evidence. Per-clause attribution would need a host with SGL_HAS_NVAPI: ON.

• Only spirv is observed failing; there is no metal/CUDA/CPU job in the dispatch matrix that surfaced this. Diagnostic suppression on those targets follows by construction (the guard excludes them), but their runtime and layout behaviour is unverified — see the capability-set note below.

• The logs also carry error[E39999] (import failed) and fatal error[E40003] (compilation ceased). Both are cascade wrappers emitted immediately after each E36121, not independent root causes.

• One non-diagnostic side effect of removing the raw capability entry, bounded. Slang's slang-type-layout.cpp:3549 iterates the raw CompilerOptionName::Capability array to compute specificCapabilityRequested, and :3559-3563 adds CapabilityName::descriptor_handle iff !specificProfileRequested && !specificCapabilityRequested. The promotion itself calls only addUnexpandedCapabilites + setTargetCaps, i.e. it directly mutates the target capability set; downstream layout and lowering code then consults that set, so the effect is not confined to diagnostics. Dropping the entry could therefore flip that boolean and change the cooked capability set.

  That flip cannot occur on the targets involved here. specificProfileRequested is true whenever a real profile is set, and slangpy sets one only for d3d12 and vulkan (shader.cpp:452-454, whose SGL_CHECK also rejects SLANG_PROFILE_UNKNOWN); TargetDesc.profile otherwise defaults to SLANG_PROFILE_UNKNOWN. So on vulkan — where all 28 failures reproduced — specificProfileRequested is already true, descriptor_handle was never being added, and removing the capability entry changes nothing in this auto-promotion path. On d3d12 the real profile likewise prevents auto-promotion; and where NVAPI is available the guard also retains the request.

  For metal / cuda / wgpu / cpu the profile stays UNKNOWN, so those are the only sessions where dropping the entry can flip specificCapabilityRequested and re-enable descriptor_handle auto-promotion. This matters under the pinned 2026.12, not only under #11225: maybePromoteDescriptorHandleCapability is present in the pinned release too (slang-type-layout.cpp:3519), and because this fix is deliberately pin-independent it reaches users well before #11225 merges. The correct risk baseline is therefore the pinned compiler, not the post-#11225 world.

  Tested against the pinned slangc 2026.12 with a shader storing through a DescriptorHandle<RWStructuredBuffer<float>> in a ParameterBlock. What I measured was the compilation result and the diagnostics. Generated layout, emitted code and struct offsets were not compared, so any downstream layout or lowering effect of the capability-set change is untested.

  All four of ptx, metal, cpp, wgsl compile successfully (rc=0) both with and without the stray entry. One diagnostic difference appears, and it goes the helpful way: on ptx the stray entry produces an extra warning[E41012]: profile implicitly upgraded ... 'cuda_sm_2_0', which the guard removes. That warning also appears without any DescriptorHandle in the shader, so it is caused by the stray capability itself rather than by promotion — and slangpy disables E41012 by default (shader.cpp:346), so a default session suppresses it — though enable_warnings is applied afterwards (:363-364), so a user who re-enables it could see the difference.

  This is evidence of no adverse change for this shader shape under the pinned compiler, not a proof of equivalence for all shaders, and it is untested on a real target device. Worth a follow-up issue rather than expanding this PR.

On guard consistency — all four runtime sites agree

Since the Linux A/B validates the mechanism rather than the predicate (see the caveat above), consistency with the existing NVAPI guards carries much of the justification for the predicate itself. That argument holds cleanly. Every runtime NVAPI condition in this file uses the identical two-clause form:

site	construct
:250	if (SGL_HAS_NVAPI && m_device->type() == DeviceType::d3d12) — module create
:406	if (SGL_HAS_NVAPI && device_type == DeviceType::d3d12) — this fix
:508	(SGL_HAS_NVAPI && m_device->type() == DeviceType::d3d12) ? "1" : "0" — SGL_ENABLE_NVAPI define
:659	if (SGL_HAS_NVAPI && m_device->type() == DeviceType::d3d12) — module link

The one NVAPI condition without a device term, #if SGL_HAS_NVAPI at :510-517 (NV_SHADER_EXTN_SLOT and the NVAPI include path), is not a drifted guard — it answers a different question. #if is a compile-time availability gate ("were NVAPI headers built into this binary at all"), whereas the four sites above are per-session runtime decisions. Its contents don't need the device term: the -I argument is addressed to "dxc", which only runs for HLSL/DXIL, and NV_SHADER_EXTN_SLOT has no in-repository consumer (grep finds only the define site — the NVAPI headers reached via that include path may consume it, but they too are only reachable on the DXIL path).

A runtime if could of course be nested inside that block, so this is a statement about what the site needs, not about what C++ permits. Adding one would change what is passed on Windows + vulkan sessions — a configuration this container cannot exercise (SGL_HAS_NVAPI: OFF, no D3D12) — so it is left alone rather than folded into a PR whose claims are currently verified.

Sequencing

.github/workflows/ci-latest-slang.yml's build-pr job checks out slangpy with no ref: (:94-97), so slangpy is always built from its default branch; client_payload controls only the slang ref. SlangPy Tests on slang#11225 therefore stays red until this guard is on main — an open PR will not flip it. SlangPy Tests is also not bot-rerunnable; a human must re-dispatch after merge.

This does not make anything urgent: #11225 is currently unmerged and unapproved, so this guard is necessary-but-not-sufficient for it, and nothing here is racing a ready-to-merge change.

No SGL_SLANG_VERSION bump is bundled. slangpy pulls a release tarball rather than a SHA, and #11225 is in no release, so that change is two gates out — merge #11225, wait for a tag containing it, then bump the pin. Separate PR.

Summary

• Status: one-hunk fix committed and verified against affected Slang (28 E36121 without the guard, 0 with it); no observed regression against the pinned Slang.
• Link: Fixes #1087
• Verdict: hlsl_nvapi was requested for targets that cannot satisfy it; gating on the existing NVAPI predicate resolves it at the single site responsible, demonstrated by before/after against affected Slang.
• Next action: human review. Promotion out of draft, merge, and merge order relative to slang#11225 are maintainer calls. Two non-blocking follow-ups remain: D3D12 CI for the guard's true branch, and broader shader/device coverage of the descriptor_handle capability-set question.
• Blocker: none. The affected-Slang verification that was previously outstanding is complete. The two follow-ups above need CI or a target device, not further local work.

Fixes #1087

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

[nv-slang-bot]

Affected-Slang verification result — slangpy#1087 / PR #1088

Result: the fix is verified against affected Slang. Without the guard, 28 × E36121; with it, zero, and
the 28 failing test cases recover. Details below, including the controls that make each arm falsifiable.

Head is now 1dc014b. The A/B ran against 998aeb2; 1dc014b differs from it by comment text only
(git diff 998aeb2 1dc014b shows 0 changed non-comment lines), so this result carries over.

Toolchain provenance (the positive control, run first)

Local Slang built from source at pull/11225/head:

git describe --tags   ->  v2026.14.1-24-gdb61cec
slangc -v             ->  2026.14.1-24-gdb61cec

The change is present in the source: commit cf54d67 "Capabilities: error on capabilities incompatible
with target or stage" adds the diagnostic to source/slang/slang-diagnostics.lua as
requested capability '~requestedCap' is incompatible with compilation target '~target', plus
TargetRequest::checkCapabilities() in slang-target.cpp/.h.

Positive control on the binary — this directly confirms the affected diagnostic is compiled into the
library under test, rather than inferring it from a version number. (That the diagnostic comes from
#11225 specifically is established separately, by the commit ancestry above.)

| library | strings … | grep -c 'is incompatible with compilation target' |
|---|---|
| build/Release/lib/libslang.so (built from source) | 2 ✅ |
| build/slang-2026.14.1-linux-x86_64/lib/libslang.so (downloaded release) | 0 ❌ |

Trap avoided. The build tree also contains slang-2026.14.1-linux-x86_64.zip, downloaded by the
build to obtain slang-llvm. It is a released artifact and does not contain #11225, which is
still unmerged. Testing against it would have produced a clean result on both arms — a false
negative indistinguishable from success. Note the trap is self-concealing: 2026.14.1 is newer than
the pinned 2026.12, so it looks like an upgrade toward the fix while being on the wrong side of the
merge. Version-newer is not change-inclusive when the change is unmerged.

Result — three arms, all at the compiler level

Shader: a trivial [shader("compute")] entry point (no NVAPI usage), so only the capability request varies.

#	arm	command	result
1	without the guard (old behaviour: capability requested on a non-d3d12 target)	slangc -target spirv -capability hlsl_nvapi	❌ error[E36121]: requested capability 'hlsl_nvapi' is incompatible with compilation target 'spirv'
2	with the guard (new behaviour: request suppressed on non-d3d12)	slangc -target spirv	✅ compiles, 168 bytes
3	the guard's true arm (d3d12 → DXIL, capability still requested)	slangc -target dxil -profile sm_6_6 -capability hlsl_nvapi	✅ compiles, 2212 bytes

Arm 1 is the load-bearing one and it reproduces the exact CI error verbatim. Arm 2 shows suppressing
the request fixes it. Arm 3 shows the capability remains valid for the DXIL target the guard still
requests it for — i.e. the fix does not over-suppress.

What this does and does not establish

Establishes: the requested capability is the sole cause of E36121 in this minimized SPIR-V
reproduction (arms 1 and 2 differ only in that request); suppressing it on non-DXIL targets resolves the
error; and retaining it for DXIL remains valid (arm 3). Together with the single-site structural evidence,
the guard is the right change for the reported failure.

Arm 3 partially relaxes a caveat I previously published — and only the compiler-target half of it.
I had stated the guard's true arm was unverifiable in this environment. The build here is still
SGL_HAS_NVAPI: OFF, SGL_HAS_D3D12: OFF, SGL_HAS_VULKAN: ON, so the guard's true branch was never
executed through SlangSession::create_session. What arm 3 establishes is narrower and standalone:
E36121 is a compile-target diagnostic, so slangc can compile for DXIL with no D3D12 device present,
and the hlsl_nvapi/DXIL capability-target pairing that the true arm depends on is therefore valid.

It does not establish d3d12 device creation, runtime NVAPI linkage, that the Windows CI d3d12 subcases
execute, or the slangpy wiring of the true branch. Those still require D3D12 CI.

Not claimed: metal / wgsl / ptx / host-callable. Diagnostic suppression is expected by construction (the guard excludes them), but their runtime and layout behaviour is unverified — see the capability-set note in the PR body, which bounds one way removing the raw entry can affect those targets specifically.

Integration arm — slangpy built against the affected Slang

The compiler arms above isolate causation; this exercises the actual SlangSession::create_session
path — the wiring. slangpy configured with
-DSGL_LOCAL_SLANG=ON -DSGL_LOCAL_SLANG_DIR=<source build> -DSGL_LOCAL_SLANG_BUILD_DIR=build/Release
(the same mechanism CI uses at .github/actions/build-and-test-with-slang/action.yml).

Without the guard (the fix commit reverted, i.e. upstream main behaviour) — unit-test-cpp:

[doctest] test cases:   200 |   167 passed | 33 failed | 3 skipped
[doctest] assertions: 13796 | 13796 passed |  0 failed |

28 × error[E36121]: requested capability 'hlsl_nvapi' is incompatible with compilation target 'spirv' —
all 28 the identical capability/target pair, no other capability and no other target. This matches CI's
28-per-job exactly.

The failure arithmetic closes: 33 failed = 28 (E36121) + 5 (the pre-existing Git LFS asset failures
present in this container regardless of Slang version). 0 failed assertions against 33 failed cases is
the module-load-failure signature, as in CI.

So the bug is reproduced locally through slangpy's own code path, not merely inferred from CI logs.

With the guard (commit 998aeb2), same Slang, same machine:

[doctest] test cases:   200 |   195 passed | 5 failed | 3 skipped
[doctest] assertions: 15705 | 15705 passed |  0 failed |

Zero E36121. Zero nvapi mentions of any kind. The 5 remaining failures are the Git LFS asset cases
(formats, subresource_3d, subresource_mip_clamp, and the two texture_loader_stream_*), identical to
the pinned-Slang run and unrelated to shader sessions.

Summary of the A/B

arm	failures	E36121
without guard (upstream main behaviour)	33	28
with guard (998aeb2)	5	0
delta	28	28

The 28 recovered cases equal the 28 E36121 occurrences exactly. Nothing else changed between the arms:
same Slang build, same machine, same SGL_LOCAL_SLANG configuration, and the only source difference is
the one hunk in this PR.

Three notes on reading these numbers honestly. (1) The with-guard arm's zero is a meaningful zero:
the identical grep -c E36121 returns 28 on the without-guard log, so the pattern demonstrably matches
when the condition is present. (2) Assertion totals are not comparable across arms (13796 vs 15705)
because failing cases abort before their assertions run. The comparable quantities are the failure count
and its composition. (3) SGL_HAS_NVAPI is 0 on this Linux host, so this run validates the guard as a
whole — in fact it short-circuits at the first clause, so the device_type comparison is never
evaluated and this run cannot isolate either conjunct. What it establishes is the mechanism: not
requesting hlsl_nvapi is what fixes the SPIR-V failures. The predicate is justified separately —
the device clause by the Windows job still failing on vulkan with SGL_HAS_NVAPI: ON, and the
availability clause by consistency with the module create/link sites.

The runtime-resolved library was checked too, not just the one on disk: ldd sgl_tests resolves slangpy's
copied libslang-compiler.so.0.2026.14.1, and that file also returns 2 for the diagnostic string — so
the tests genuinely ran against affected Slang rather than against a differently-resolved library.

git merge-base --is-ancestor db61cec origin/master confirms #11225 is not merged, consistent with the
release artifact lacking the diagnostic.

[nv-slang-bot]

D3D12 CI has now closed the caveat above

The Verification section said the guard's true branch was unexercised locally (SGL_HAS_D3D12: OFF) and that "D3D12 CI on this PR is what would establish those." That CI has now run on 1dc014b and it does.

Windows job (build (windows, x86_64, msvc, Release, 3.10), CI for head 1dc014b) configures with:

-- SGL_HAS_NVAPI: ON
-- SGL_HAS_D3D12: ON

Both clauses of SGL_HAS_NVAPI && device_type == DeviceType::d3d12 are therefore satisfiable in that job — this is the configuration in which the guard's true arm is taken and the capability is still requested.

The flags alone only make that arm possible; what shows it is reached is the test harness. tests/sgl/testing.cpp:72-83 builds the device list per platform and opens a SUBCASE per entry:

#if SGL_WINDOWS
    std::vector<DeviceType> device_types{DeviceType::d3d12, DeviceType::vulkan};
...
    for (DeviceType device_type : device_types) {
        SUBCASE(enum_to_string(device_type).c_str())

So on Windows every non-skipped TEST_CASE_GPU executed by the job runs a d3d12 subcase (the suite reports 3 skips, two of which are TEST_CASE_GPUs marked doctest::skip()), and the job's Unit Tests (C++) step completed:

[doctest] test cases:   200 |   200 passed | 0 failed | 3 skipped
[doctest] assertions: 20238 | 20238 passed | 0 failed |

200/200, zero E36121, zero hlsl_nvapi diagnostics of any kind. So requesting the capability on d3d12 under the guard still compiles every shader compilation exercised by the suite — the fix does not over-suppress, now demonstrated on a real D3D12 build rather than inferred.

Two honest notes on reading this:

• Comparing against the same commit's Linux job (SGL_HAS_D3D12: OFF): 20238 assertions on Windows vs 17168 on Linux, +3070. That is consistent with the extra d3d12 device subcases executing, but the assertion delta alone does not prove which subcases ran — Windows-only test cases could also contribute.
• I did not re-derive this from failure stacks, because there are none: doctest prints DEEPEST SUBCASE STACK REACHED only while logging failures, so with 0 failures that signal is absent by construction and its absence is not evidence either way. The load-bearing facts are the two configure flags, the testing.cpp:72-83 device matrix putting d3d12 in the subcase list for every non-skipped GPU test on Windows, and 200/200 passing with no NVAPI diagnostic.

Full CI on 1dc014b: 13 success, 1 skipped (Claude Code Assistant), 0 failures.

What remains open is unchanged and unaffected by this: the descriptor_handle capability-set question for metal/cuda/wgpu/cpu, which is a follow-up rather than a gate.

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