# [Vulkan] Precise FMA-based compensated summation is wrong unless the correction helper is noinline

[ccummingsNV]

slang-noinline-repro.zip

Summary

On an NVIDIA GB300 with driver 610.43.02, a small Neumaier compensated-summation
shader returns the wrong result through Vulkan when its correction helper is
inlined. Adding [noinline] to the helper makes the same shader return the
expected value. The CUDA target returns the expected value both with and
without [noinline].

The Slang session uses SlangFloatingPointMode.precise. Slang's emitted SPIR-V
still contains the expected OpFAdd followed by GLSL.std.450 Fma for the
inlined case, but it has no NoContraction decorations. This may therefore be
a Slang precise-mode semantics/code-generation issue or a downstream NVIDIA
Vulkan compiler issue. I would appreciate guidance on which layer owns it and
how an application should express this arithmetic requirement without using a
function-boundary workaround.

Expected result

For the input sequence [16777216.0, 1.0, -16777216.0], both implementations
should return the compensated average 0.33333334.

Actual result

Vulkan:

backend:  vulkan
expected: np.float32(0.33333334)
inline:   np.float32(0.0)
noinline: np.float32(0.33333334)

CUDA control:

backend:  cuda
expected: np.float32(0.33333334)
inline:   np.float32(0.33333334)
noinline: np.float32(0.33333334)

Reproduction

The attached repro.slang has inline and noinline versions of the same helper.
The attached repro.py dispatches both variants and prints their outputs. It
requires SlangPy and NumPy.

python repro.py vulkan
python repro.py cuda

The script exits with status 1 when either output differs from the expected
value, so the Vulkan command is expected to exit 1 while the bug is present.

Readable SPIR-V can also be generated with:

slangc repro.slang -entry compute_main -target spirv-assembly \
    -profile glsl_450 -fp-mode precise -o repro-precise.spvasm

The inline path contains this operation order:

%next = OpFAdd %float %sum %value
%correction0 = OpExtInst %float %glsl Fma %float_n1 %next %sum
%correction = OpFAdd %float %correction0 %value

The noinline path is emitted as an OpFunction with DontInline and is called
with OpFunctionCall.

Environment

• Slang 2026.12
• SlangPy 0.41.0
• Linux aarch64, Ubuntu kernel 6.8.0-124-generic
• NVIDIA GB300
• NVIDIA driver 610.43.02
• CUDA toolkit 13.3, used only for the CUDA control
• Python 3.12.3
• NumPy 2.5.1

Workaround

Apply [noinline] to the correction helper for the Vulkan target. Falcor2 is
currently using this conditional workaround:

#ifdef __TARGET_VULKAN__
[noinline]
#endif
float neumaier_correction(float sum, float value, float next)

[nv-slang-bot]

Triage: already fixed on top-of-tree — please re-test on Slang ≥ 2026.13

• Status: Root cause identified and reproduced at the SPIR-V-emission layer; the missing-NoContraction symptom is already fixed on current master (and in released v2026.13+). You are on 2026.12, which predates the fix.
• Verdict: This is a stale-version manifestation of -fp-mode precise has no effect on SPIR-V output (no NoContraction emitted) #11933 ("-fp-mode precise has no effect on SPIR-V output (no NoContraction emitted)", CLOSED), fixed by PR Emit NoContraction under -fp-mode precise on direct SPIR-V #11935 (commit 33f9ed0c, 2026-07-07). That commit first shipped in v2026.13 (tagged 2026-07-08); the v2026.12 you're running was cut 2026-06-25, before the fix. It is not a duplicate of the still-open precise qualifier is ignored on SPIR-V: no NoContraction, and the expression is algebraically reassociated #12198 (that tracks the per-variable precise qualifier in the default fp-mode; you are using the global SlangFloatingPointMode.precise, which -fp-mode precise has no effect on SPIR-V output (no NoContraction emitted) #11933/Emit NoContraction under -fp-mode precise on direct SPIR-V #11935 owns).
• Evidence: Compiling your exact attached repro.slang with -fp-mode precise -target spirv-assembly:
  • Your captured repro-precise.spvasm (2026.12): 0 NoContraction decorations across the whole module — which is why [noinline] was needed (the OpFunction/OpFunctionCall boundary is an optimization barrier the driver won't contract across; nothing was actually marked precise).
  • Current master (2026.13.1-50): 32 NoContraction decorations, on a byte-for-byte identical instruction graph. The specific add the driver was contracting — %154 = OpFAdd %153 %133 (i.e. fma(-1, next, sum) + value) — now carries NoContraction, in both the inlined and the [noinline] bodies.
• Next action: Please re-run the repro on ≥ v2026.13 (or current release). Expected: with global -fp-mode precise the inlined path is now decorated and the #ifdef __TARGET_VULKAN__ [noinline] workaround should no longer be required. To answer your two questions directly: (1) the missing-NoContraction symptom was a Slang code-generation gap (the direct SPIR-V emitter previously ignored -fp-mode precise entirely), now fixed; (2) the intended way to express this requirement is simply -fp-mode precise on 2026.13+ — no function-boundary workaround.
• Blocker / caveat (honest hedge): I verified the compiler-side symptom (missing → present NoContraction) on top-of-tree; I could not re-run the runtime result on your GB300 + driver 610.43.02 (no matching hardware here). One nuance: NoContraction is applied to the surrounding OpFAdds, not to the OpExtInst GLSL.std.450 Fma itself (per the SPIR-V spec, NoContraction on an already-fused Fma is not meaningfully applicable, and the Fma originates from your fma() call, not from Slang contraction). If the wrong result persists on ≥2026.13, the remaining question would be whether NoContraction on the adds is a sufficient anti-contraction guard for that specific driver — i.e. a downstream NVIDIA-Vulkan-compiler question rather than a further Slang change. Please let us know either way.

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

[jhelferty-nv]

@ccummingsNV It sounds like this is already fixed, but will need a slang release update in slangpy. (slangpy currently uses 2026.12, needs a newer version.)

[nv-slang-bot]

@jhelferty-nv Confirmed, and filed on the SlangPy side: shader-slang/slangpy#1092.

Verifying your figure rather than inheriting it — you're right about main, with one wrinkle:

• external/CMakeLists.txt:85 on slangpy main is indeed SGL_SLANG_VERSION "2026.12", and that's also what the latest release (v0.43.1) bundles.
• @ccummingsNV was on SlangPy 0.41.0, which pins 2026.5.2 — older still. Either way the fix is absent.
• The mechanism is a pinned prebuilt release tarball (not a submodule/SHA), so the version only moves on a manual bump.

Containment of the fix commit 33f9ed0c (PR #11935) per release tag — ahead = absent, behind = present:

Slang tag	Published	status	Fix present?
v2026.5.2	2026-03-31	ahead	❌
v2026.12	2026-06-25	ahead	❌
v2026.12.1	2026-06-30	ahead	❌
v2026.12.2	2026-07-01	ahead	❌
v2026.13	2026-07-08	behind	✅
v2026.13.1	2026-07-13	behind	✅
v2026.12.0.1	2026-07-16	diverged	❌
v2026.14	2026-07-24	behind	✅
v2026.14.1	2026-07-30	behind	✅

Two traps worth stating explicitly, since either would produce a bump that looks like a fix and isn't:

• The 2026.12.x patch line does not carry the fix — a patch-level bump won't do it. slangpy needs ≥ 2026.13. (Corrected: this line previously said slangpy#1092 proposes 2026.14.1. The change that shipped — draft Update bundled Slang to 2026.13.1 slangpy#1093 — pins 2026.13.1, the earliest release carrying all four relevant fixes. 33f9ed0c and 22d27646 are in v2026.13, but caa2ff45 and 85d79c676 first appear in v2026.13.1, so 13 is not sufficient and 14.1 is not necessary.)
• v2026.12.0.1 is the trap. Published 2026-07-16, later than v2026.13.1, so by publish date it looks like the newest available — but it is a patch cut from the older branch: v2026.12 +1 commit (f17d619e, Memoize shared Val and type DAG traversals #12106), and against the fix it is diverged with ahead_by=134, behind_by=1. Its assets match the naming SlangPy's CMake builds, so it is a selectable pin value that silently lacks the fix. (diverged is a distinct status from ahead — GitHub compare returns four: ahead/behind/identical/diverged, and only behind/identical mean present. Positive control: compare/33f9ed0c...33f9ed0c → identical.)

I also confirmed this against the shipped binaries rather than relying on tag ancestry, since a release could in principle carry a cherry-pick under a different SHA. Compiling a minimal compensated-summation kernel with the official linux-x86_64 assets: 2026.12.0.1 emits 0 NoContraction under -fp-mode precise, 2026.14.1 emits 8, on an identical instruction graph (6 OpFAdd+OpExtInst both), with both emitting 0 in the default fp-mode. So the behavioral difference is real and attributable to the flag.

Not a routine bump, for one specific reason: slangpy's last pin move was a downgrade (slangpy#1016, "Newer slang releases have severe perf regressions"), and nothing measures SlangPy's own runtime/dispatch throughput — #1016 never said which perf it meant. That's a maintainer call, captured as the first open question on slangpy#1092.

(Corrected — this paragraph previously claimed "there is no perf data for ≥2026.13" because the benchmark workflow has the "build latest Slang" path commented out. Both halves were wrong. Slang compile-perf data for ≥2026.13 does exist and is published, per-release and daily-ToT, at shader-slang/slang-compile-perf; on the minimal workload linkAndOptimizeIR runs 3.55 ms at 2026.12 vs 1.03 ms at 2026.13.1, i.e. the bump improves compile time. And the workflow is not blind: ci-benchmark.yml triggers on schedule + workflow_dispatch and its active configure step uses the bundled pin, so it benchmarks whatever is pinned — what is commented out is only the unpinned-upstream override. The lane simply never proactively tests Slang newer than the pin. Inferring "no data exists" from "one lane looks disabled" was invalid.)

@ccummingsNV in the meantime, if you build SlangPy from source you can get the fix today without waiting for the pin, via -DSGL_LOCAL_SLANG=ON -DSGL_LOCAL_SLANG_DIR=<your slang checkout>. On a pip-installed wheel, the [noinline] workaround is still needed until the pin moves and a wheel ships.

Edited to correct this comment's own content: the first version collapsed the tags into two rows and omitted v2026.12.0.1 — the one tag whose publish date most invites the wrong bump; the second mis-stated its commit-distance numbers. Verdict unchanged throughout, and confirmed against the shipped binaries rather than tag ancestry alone. A later edit corrected the proposed pin (13.1, not 14.1) and withdrew the "no perf data" claim — see the two correction notes above. Note the acceptance test below compares 2026.12.0.1 against 2026.14.1, i.e. neither the old pin nor the proposed one, so it brackets the fix rather than testing the shipped choice; containment in 13.1 rests on git merge-base --is-ancestor.

Nothing further is needed on the Slang side — the compiler fix is released (33f9ed0c in v2026.13+). This issue stays open pending @ccummingsNV's re-test on ≥ 2026.13; it is open for want of a confirmation, not because of an unfixed compiler defect. Tracking the rest on slangpy#1092, where the pin bump is now draft PR slangpy#1093.

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

[kaizhangNV]

Close the issue as the slang version is updated in Slangpy