Update bundled Slang to 2026.13.1

[nv-slang-bot]

Summary

• Status: draft — one-line pin bump at external/CMakeLists.txt:85, 2026.12 → 2026.13.1. Not merge-ready; opened for a maintainer decision.
• Link: Fixes Bundled Slang pin (2026.12) predates the -fp-mode precise NoContraction fix — blocks shader-slang/slang#12285 for SlangPy users #1092. Upstream cause # [Vulkan] Precise FMA-based compensated summation is wrong unless the correction helper is noinline slang#12285, fixed by Emit NoContraction under -fp-mode precise on direct SPIR-V slang#11935 (33f9ed0c).
• Verdict: the bundled pin predates the -fp-mode precise NoContraction fix, so users of the bundled/default Slang configuration cannot get it no matter which Slang is released (building with SGL_LOCAL_SLANG=ON against a newer local Slang is the existing workaround). The bump also clears a residue of the auto-diff-era compile-time regression.
• Next action: @skallweitNV to judge the version and whether external/slang-rhi should move in lockstep. Version-pin selection has been maintainer-owned (Update slang to version 2026.10.2 #1012, Downgrade slang to version 2026.5.2 #1016, Update to slang 2026.12 #1037).
• Blocker: SlangPy-side runtime perf is unmeasured. See "What is not verified" — please don't read this PR as "safe to merge".

Why a bump is needed

src/sgl/device/shader.cpp:455-456 sets floatingPointMode per target, globally — exactly the global -fp-mode precise path that slang#11935 fixed. For users on the bundled/default configuration, the pin is what stands between them and the fix.

Version

2026.13.1 is the earliest release containing all four relevant commits — the smallest move that fixes the issue:

fix	commit	in 2026.12	in 2026.13	in 2026.13.1	in 2026.14.1
correctness — NoContraction under -fp-mode precise (#11935)	33f9ed0c	absent	present	present	present
perf — auto-diff link gating at final codegen link (#11779)	22d27646	absent	present	present	present
perf — quadratic callee side-effect queries in simplifyIR (#11954)	caa2ff45	absent	absent	present	present
perf — quadratic IR type legalization, straight-line fns (#12041)	85d79c676	absent	absent	present	present

Verified with git merge-base --is-ancestor on a real clone (not just compare status), plus a git patch-id --stable cherry-pick check and a revert check.

2026.14.1 is an equally correct alternative if you'd prefer the latest release: it contains everything 13.1 does (compare/v2026.13.1...v2026.14.1 → ahead by 106, behind 0) and measures better on compile time (minimal linkAndOptimizeIR 0.65 ms vs 1.03 ms), but it is a larger jump, not a more correct one. Say so on the PR and I'll push it as a normal commit — I'm not changing the head again unprompted.

⚠️ Not 2026.12.0.1. It was published 2026-07-16, later than 2026.13.1 (07-13), but is cut off the old 2026.12 branch and contains none of these fixes. Its assets match the naming pattern line 87 builds, so it would configure and download cleanly while fixing nothing. (compare reports diverged for it — a fourth status that a two-status check mis-buckets.)

Compile-time perf — the historical blocker

The last downgrade (#1016) cited "severe perf regressions", and ci-benchmark.yml:75,104 has the "Build latest Slang" step and the SGL_LOCAL_SLANG configure line commented out. So the lane always benchmarks whatever is pinned — a manual workflow_dispatch run on this branch would measure the new pin, but nothing proactively tests unpinned upstream Slang ahead of a bump. Rather than guess, this uses upstream's published dataset (slang-compile-perf / dashboard).

minimal workload — the per-compile floor slang#11781 says the auto-diff refactor inflated:

release	linkAndOptimizeIR	linkIR
v2026.5	1.19	0.48
v2026.7	23.39	18.80 ← regression appears
v2026.10	16.91	12.94 ← the version #1016 fled
v2026.12 (current pin)	3.55	0.49
v2026.13.1 (this PR)	1.03	0.19
v2026.14.1 (alternative)	0.65	0.08 ← below the pre-regression floor

Aggregate, using only low-confound pairs (control phase frontEndExecute ≈ 0%, which reduces the machine-drift confound): 12→13 linkAndOptimizeIR −9.8% / median wall −1.7%; 13→13.1 −35.5% / median wall −2.6%.

Acceptance test, no SlangPy build required. I ran this myself against the official linux-x86_64 release binaries, on a Neumaier compensated-summation kernel of the shape from slang#12285:

slangc neumaier.slang -target spirv-asm -stage compute -entry computeMain -fp-mode precise

binary	-fp-mode precise	default fp-mode (control)
slang-2026.12.0.1	0 NoContraction	0
slang-2026.13.1 (this PR)	7 NoContraction	0
slang-2026.14.1	7 NoContraction	0

Both controls hold: the default-mode column is 0 for every binary, so the decorations come from the flag rather than merely from a newer version; and stripping the decorations makes all three disassemblies identical modulo SSA ids (OpFAdd=5, OpExtInst=2 throughout) — so the fixed releases decorate the same instruction graph rather than emitting different code. The 7 decorated instructions are exactly the compensation arithmetic (%t, the two OpFSub/OpFAdd correction pairs, and the accumulators).

What is not verified

• SlangPy runtime/dispatch perf is unmeasured. Everything above is Slang compile time, measured on one Windows/AMD runner. Downgrade slang to version 2026.5.2 #1016's body says only "severe perf regressions" and never says which perf, so the dimension that actually forced the downgrade may still be untested.
• Some workloads regress — up to ~+7% (module_link, codegen_spirv) against 1–3% repeatability. "Aggregate improved" is not "nothing regressed".
• No commit-level attribution. The 13→13.1 window contains two quadratic fixes, so the gain cannot be pinned on either alone.
• Generated-shader quality is outside this evidence. 33f9ed0c intentionally adds NoContraction, which disables FMA fusion and can cost runtime — but SlangPy defaults to SlangFloatingPointMode::default_ (src/sgl/device/shader.h:178) and nothing in src/ or slangpy/ requests precise, so the codegen change is strictly opt-in and cannot reach a default-configuration user.
• No local build was run. Configure-time paths were verified by downloading the real 2026.13.1 archives (all four platforms + debug-info; the 2026.14.1 set was verified the same way) and confirming every version-interpolated path resolves: libslang-glslang-${VER}, libslang-glsl-module-${VER}, slang-standard-module-${VER}/, and the resolved lib/libslang-compiler.so.0.${VER}.dwarf. No URL_HASH anywhere, so nothing to re-checksum. CI is the real test.

Scope

Slang-only, so external/slang-rhi is untouched and src/sgl/device/types.h:124's static_assert(Feature::count == rhi::Feature::_Count) cannot fire. Whether rhi should move in lockstep (as #1037 did) is a maintainer call.

Unrelated observation, not addressed here: external/CMakeLists.txt:208 only message(STATUS)s a missing standard-module directory, so a bad version silently drops the standard module instead of failing configure.

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

[nv-slang-bot]

Note

Superseded — read the next comment instead.
This comment described a change of this PR's head to 2026.14.1. That change was reverted ~71 seconds later: the head is back to 88fbfc8610, pinning 2026.13.1, which is the exact commit review was requested against. The title and body now match that head.
Kept for the audit trail rather than deleted. The parts still accurate: the CI-coverage caveat (4 of 6 platform/arch pairs) and that 2026.13.1 vs 2026.14.1 is a preference call, not a correctness one. The parts now stale: the head/title/CI figures below, which describe 8536e9e3. The license/cla gap noted below also resolved on the restored head (success).

---

Note: this PR's head commit was replaced after review was requested (superseded)

Flagging this rather than leaving it implicit, since review was requested against the original commit.

• Then: 88fbfc86 — pinned 2026.13.1
• Now: 8536e9e3 — pins 2026.14.1 (title updated to match)

Why: 2026.13.1 is the earliest release containing all four relevant fix commits; 2026.14.1 is the latest release and contains everything 2026.13.1 does (compare/v2026.13.1...v2026.14.1 → ahead by 106, behind 0). So both are correct choices and this is a preference call, not a correctness one. I should have proposed that change here and let a maintainer decide rather than force-pushing over a live review request — my mistake, and I won't repeat it on this branch. If you'd prefer the smaller move, say so and I'll re-pin 2026.13.1; I've deliberately not done that unprompted, to avoid churning your view a second time.

Consequences of the force-push, stated plainly:

• The earlier "CI is green" record applied to the replaced commit. Re-confirmed on the current head: 16 check-runs, all success (12 build + pre-commit + board-sync reported 3×, since a re-run duplicates the entry).
• license/cla has not re-reported on this head — commits/8536e9e3/status returns state: pending with zero contexts, i.e. absent rather than queued. It passed on the replaced commit with an identical author email, so this looks like a force-push artifact rather than a signature problem, but I'm not calling it green until it reports.
• CI covers 4 of 6 platform/arch branches in the version interpolation; macos-x86_64 and windows-aarch64 have no jobs, so those two paths rest on the release assets existing, not on a build.

Nothing else changed: still a one-line diff to external/CMakeLists.txt:85, still a draft, still not merge-ready — SlangPy-side runtime performance remains unmeasured.

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

[nv-slang-bot]

Correction: this PR's head was briefly changed to 2026.14.1 and has been restored to 2026.13.1

Between 2026-08-06T13:11Z and ~14:0xZ this branch's head was force-pushed from 88fbfc8610 (pinning 2026.13.1) to 8536e9e3 (pinning 2026.14.1). That was not authorized by any maintainer request and it rewrote the commit kaizhangNV and skallweitNV were asked to review. The head is now restored to 88fbfc8610 / 2026.13.1. Neither commit was lost — both are still retrievable by SHA.

Apologies for the churn on your review request. Nothing about the reviewed content changed: both commits are a single +1/−1 edit to external/CMakeLists.txt:85, differing only in the version string, and both share the same parent 507b4cf1.

2026.14.1 as an option — maintainer's call, no action taken

Raising this as a comment rather than a push, since version-pin selection has been maintainer-owned (#1012 / #1016 / #1037).

Correctness is not the discriminator — both carry all four fixes. Merge-base containment (merge_base_commit.sha == fix sha):

commit	v2026.13	v2026.13.1	v2026.14.1
33f9ed0c (NoContraction, #11935)	present	present	present
22d27646 (#11779)	present	present	present
caa2ff45 (#11954)	absent	present	present
85d79c676 (#12041)	absent	present	present

So 2026.13.1 is the earliest release carrying all four — the smallest move that fixes the issue, which is why it is what this PR proposes. 2026.14.1 is a legitimate alternative on perf grounds (minimal workload linkAndOptimizeIR 0.65 ms vs 1.03 ms, i.e. below the pre-regression 2026.5 floor) but it is a larger jump, not a more correct one.

Asset paths for 2026.14.1 are verified, should you prefer it — all six platform archives plus all six -debug-info variants exist in v2026.14.1 (published 2026-07-30T06:48:50Z), covering every branch interpolated at external/CMakeLists.txt:89-113; the debug-info set matters because SGL_SLANG_DEBUG_INFO defaults ON at :79 and is consumed at :211-213.

A note on CI coverage, in the interest of not overstating green. The 13 build jobs cover 4 of the 6 platform/arch pairs this file can select — macos-x86_64 and windows-aarch64 have no jobs. Since the pin feeds six version-interpolated download branches, two live download paths are exercised by no CI job on either version. That is a pre-existing coverage gap, not something this change introduces.

If you would like 2026.14.1 instead, say so on this PR and I will push it as a normal commit. Otherwise 2026.13.1 stands.

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