hlsl_nvapi capability requested unconditionally — breaks all non-HLSL targets under slang#11225

[nv-slang-bot]

Summary

SlangSession::create_session requests the hlsl_nvapi Slang capability unconditionally, while the NVAPI module that capability exists to support is requested only for SGL_HAS_NVAPI && DeviceType::d3d12. The capability request is therefore strictly broader than the link it backs.

Slang has tolerated this mismatch silently until now. shader-slang/slang#11225 ("Capabilities: error on capabilities incompatible with compilation target", fixes #4422) makes an incompatible capability request a hard error, so every non-HLSL target now fails to load any module:

error[E36121]: requested capability 'hlsl_nvapi' is incompatible with compilation target 'spirv'
error[E39999]: import failed due to compilation error
fatal error[E40003]: compilation ceased

This is a downstream bug in SlangPy, not a defect in slang#11225 — the Slang change is working as designed and is correctly surfacing a pre-existing latent looseness on our side. slang#11225 is currently blocked solely by our SlangPy Tests status.

The asymmetry (verified at main @ 086ca32)

Capability requested with no target/platform condition — src/sgl/device/shader.cpp:404-408:

// Add hlsl_nvapi capability.
session_options.add(
    slang::CompilerOptionName::Capability,
    int(m_device->global_session()->findCapability("hlsl_nvapi"))
);

The NVAPI module it backs is guarded in both places it is used:

• shader.cpp:250 — module create: if (SGL_HAS_NVAPI && m_device->type() == DeviceType::d3d12)
• shader.cpp:656 — module link: same predicate
• shader.cpp:503-506 — the SGL_ENABLE_NVAPI macro define already branches on exactly this predicate, in the same function as the unguarded request

There is also an adjacent TODO at shader.cpp:409-413 recording that passing all detected capabilities "leads to slang compilation errors and needs more investigation" — the same underlying looseness.

Evidence

CI run: https://github.com/shader-slang/slangpy/actions/runs/30779697035 (slangpy main @ 086ca32 × slang#11225 head db61cec)

sgl_tests: 172 passed / 28 failed / 3 skipped, but 0 assertions failed (18535/18535 windows, 15593/15593 linux). Every one of the 28 is a thrown Failed to load slang module ... followed immediately by E36121 — no test logic failed, module loading did.

All 28 failures are the vulkan subcase; zero d3d12 failures. Extraction method, so this is checkable: doctest prints a multi-line DEEPEST SUBCASE STACK REACHED header with the subcase name on the following indented line, and windows.log is CRLF, so the naive one-line grep is vacuous — tr -d '\r' < log | grep -A2 'DEEPEST SUBCASE STACK REACHED' yields 28 vulkan, 0 d3d12 per job, and grep -c on the header returns 28, confirming the enumeration is complete rather than partially matched.

Correction (2026-08-03): an earlier version of this issue stated the d3d12 subcases "did execute and all passed" and called that decisive. That was an inference presented as an observation, and it is withdrawn. The logs contain no device-creation line, and every d3d12 string in windows.log is a build-artifact path. The defensible version: tests/sgl/testing.cpp:73 iterates device_types{d3d12, vulkan} on Windows vs {vulkan} on Linux, and Windows reports 18535 assertions against Linux's 15593 — consistent with d3d12 executing and not failing, but not direct evidence. Note the confound: both platforms report identical case counts (200 / 172 passed / 28 failed / 3 skipped), so the assertion delta could also come from Windows-only or D3D12-only assertions inside otherwise-shared cases rather than from a second device iteration. What would actually settle it is D3D12 CI on the PR. The SGL_HAS_NVAPI ON/OFF contrast below is unaffected and remains the load-bearing evidence.

The two platforms fail for two different reasons, which confirms both halves of the predicate are load-bearing:

Platform	Configure	nvapi module	Result
linux-gcc	SGL_HAS_NVAPI: OFF	never created or linked	vulkan fails — capability requested for a module absent from the build entirely
windows-msvc	SGL_HAS_NVAPI: ON	created, linked for d3d12 only	d3d12 passes; vulkan fails — capability requested for a non-HLSL target

Deterministic: identical 28 cases on linux-gcc and windows-msvc, across both run attempts. Not a flake.

Affected test areas: hot_reload::* (13), refl::* (6), func::* (5), cursors::* (2), device::shader, device::texture_loader_batched_uploads.

Suggested fix

Gate the capability request with the same predicate already used at :250 / :656 / :503-506:

if (SGL_HAS_NVAPI && device_type == DeviceType::d3d12) {
    session_options.add(
        slang::CompilerOptionName::Capability,
        int(m_device->global_session()->findCapability("hlsl_nvapi"))
    );
}

device_type is already a local in this function (shader.cpp:307, = m_device->type()), and :381 establishes the in-function precedent for a d3d12-conditional block.

Scope notes:

• The fix is a green no-op against released Slang. external/CMakeLists.txt:85 pins SGL_SLANG_VERSION "2026.12", which predates #11225, so normal CI cannot regress on it — it only changes behaviour once a Slang containing #11225 is picked up.
• vulkan is the only non-HLSL target proven affected by this run (no metal/CUDA/CPU job exists in the dispatch matrix). By the same reasoning metal/cuda/wgsl should be affected too, but that is inference, not observed here.
• Sequencing: .github/workflows/ci-latest-slang.yml checks out slangpy at its default branch for repository_dispatch runs — client_payload controls only the slang ref. So SlangPy Tests on slang#11225 will keep failing until this fix is merged to slangpy main; an open or draft PR does not change that status.

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

[nv-slang-bot]

Triage complete — fix verified, maintainer-approved, CI green. Draft PR awaiting promotion and merge.

Root cause and the suggested patch are in the issue description above. This comment tracks chain state and is edited in place as it changes.

• Status: Draft PR Only request hlsl_nvapi capability where the NVAPI Slang module is linked #1088 (1dc014b), one hunk in src/sgl/device/shader.cpp, +8/−5. Approved by skallweitNV (MEMBER) on 1dc014b; CI green — 13 success, 1 skipped, 0 failures; zero open review threads. Still draft=true, merged=false, Fixes #1087. As of 08-05: @jkwak-work is assigned and both @skallweitNV and @jkwak-work are listed as requested reviewers, so a second review appears outstanding despite the existing approval.
• Link: #1088; A/B result in comment 5164941137. Blocks Capabilities: error on capabilities incompatible with compilation target (fixes #4422) slang#11225, where SlangPy Tests is the only failing check — coordination note; that PR is working as designed and needs no change.
• Verdict: Confirmed. The capability request is now gated on SGL_HAS_NVAPI && device_type == DeviceType::d3d12, matching the module create (:250) and link (:660) sites. Verified against Slang built from #11225: 28 × E36121 without the guard, 0 with it, and the 28 failing cases recover. Three slangc-level arms isolate causation independently (spirv + hlsl_nvapi → error; spirv alone → compiles; dxil + hlsl_nvapi → compiles). Scope note: because SGL_HAS_NVAPI is 0 on Linux, the predicate short-circuits before the device comparison, so this A/B validates the mechanism — that requesting hlsl_nvapi is what breaks non-HLSL targets — while the choice of two-clause predicate rests on consistency with the four runtime NVAPI sites plus the Windows CI evidence.
• Next action: Promotion out of draft and merge — both maintainer-only. One approval is in hand and CI is green, but a review request to @jkwak-work is outstanding, so review may not be complete. An approval is not authorization to promote, so the PR is deliberately left as a draft. Merge order versus slang#11225 is also a maintainer call. See comment 5195534088 for current state — including that Only request hlsl_nvapi capability where the NVAPI Slang module is linked #1088 is 2 commits behind main. Sequencing, for whoever picks this up: this guard must be merged to slangpy main before slang#11225 can go green, because ci-latest-slang.yml's build-pr job checks out slangpy with no ref: and so always builds the default branch — a draft or open PR will not flip that status. There is no time pressure: #11225 is unmerged with no human approvals and a requested reviewer outstanding. Landing early is low-risk — the guard is a no-op against released Slang, since SGL_SLANG_VERSION is pinned to 2026.12, which predates #11225. Any pin bump belongs in a separate PR and is two gates away (#11225 must merge, then ship in a release tag). Note that SlangPy Tests cannot be re-run by automation, so a human must re-dispatch that run after this merges.
• Blocker: None. The true-branch caveat is now closed by evidence. The Windows CI job configures SGL_HAS_NVAPI: ON + SGL_HAS_D3D12: ON — exactly the configuration where the guard keeps the capability request — and passes 200/200 cases with 20238 assertions and zero E36121/hlsl_nvapi, so the guard does not over-suppress on d3d12. d3d12 genuinely executes there rather than merely being enabled: tests/sgl/testing.cpp:72-83 iterates {d3d12, vulkan} on Windows with a SUBCASE per device. This is what an earlier version of this comment named as the only thing that could establish the branch. One follow-up remains, non-blocking: On metal/cuda/wgpu/cpu, where SlangPy requests no profile, removing the capability entry re-enables descriptor_handle auto-promotion (slang-type-layout.cpp, present in pinned 2026.12) for shaders using DescriptorHandle<T>. That is a behaviour change under the pinned compiler, not only under #11225; one shader shape showed no adverse compile result, and broader coverage is the follow-up. Neither target appears in the two-job CI matrix.

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

[jhelferty-nv]

@zangold-nv It looks like the bot is giving us a heads-up that slang#11225 we're working on might cause some downstream issues with slangpy?

@ccummingsNV Flagging this for your awareness

[nv-slang-bot]

Not a heads-up — a confirmed downstream break, already fixed. The fix is #1088 (one hunk in src/sgl/device/shader.cpp, +8/−5): SlangPy requested the hlsl_nvapi capability unconditionally while the NVAPI module backing it is gated on SGL_HAS_NVAPI && m_device->type() == DeviceType::d3d12, so the capability request was strictly broader than the link it backs. shader-slang/slang#11225 correctly turns that latent mismatch into a hard error on every non-HLSL target. slang#11225 needs no change.

#1088 is approved by @skallweitNV (08-03) and CI is green — 13 success / 1 skipped / 0 failures. @jkwak-work is assigned and has a review request outstanding. The PR is still a draft, so promotion out of draft and merge are maintainer-only steps.

@zangold-nv — this merge is load-bearing on your PR. slangpy/.github/workflows/ci-latest-slang.yml's build-pr job checks SlangPy out with no ref:, so it always builds SlangPy's default branch; client_payload controls only the slang ref. SlangPy Tests on #11225 therefore stays red until this guard is merged to main — a draft or open PR will not flip it. SlangPy Tests also can't be re-run by automation, so a human will need to re-dispatch that run after the merge.

Low-risk to land early: the guard is a no-op against released Slang, because SGL_SLANG_VERSION is pinned to 2026.12, which predates #11225. One mechanical note — #1088 currently reports mergeable_state=behind, 2 commits behind main (08ae47a4e #1084, 507b4cf16 #1078). Those two touch only workflow files and slangpy/tests/slangpy_tests/test_array.py, nothing in src/sgl/, so bringing the branch up to date is conflict-free — worth checking whether your branch-protection settings require it before merging. (I can't read the protection settings, so I can't tell whether that blocks the merge button or whether updating would affect the existing approval.)

Scope, stated precisely: the green CI proves no regression against the pinned 2026.12 — it cannot observe the E36121 fix, because the pin predates #11225. What actually verifies the fix is a local A/B against a source build of pull/11225/head: 28 × error[E36121] without the guard, 0 with it, and the 28 failing cases recover. Two known follow-ups, neither blocking: D3D12 CI for the guard's true branch, and the descriptor_handle auto-promotion question on metal/cuda/wgpu/cpu (a behaviour change under the pinned compiler, so it doesn't wait on #11225).

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