Add support for unified stride mode for resource descriptor heap

[chaoticbob]

Problem Description

When using VK_EXT_descriptor_heap, it's often the case that resource descriptors (buffers, images, acceleration structures) are stored in the same heap with a unified stride calculated from the max() of the descriptor size for each resource type - as returned by device properties. It would be convenience win for slang to support a unified stride within the emited SPIR-V.

Preferred Solution

Add -spirv-unified-descriptor-heap-stride to enable a unified stride using max(bufferDescriptorSize, imageDescriptorSize) as described here: https://docs.vulkan.org/features/latest/features/proposals/VK_EXT_descriptor_heap.html

[nv-slang-bot]

Triage — updated after design-scoping (automated)

• Classification: Feature request · SPIR-V code emission (spvDescriptorHeapEXT / SPV_EXT_descriptor_heap). Not a new-extension request — Slang already emits this path for DescriptorHandle<T> and exposes -spirv-resource-heap-stride / -spirv-sampler-heap-stride.
• Where it lives: Slang emits a distinct runtime-array type per descriptor element type, each used as the type operand of OpUntypedAccessChainKHR with its own ArrayStride, all indexing one heap binding (source/slang/slang-emit-spirv.cpp:7186-7227, :7335-7343). With arrayStride == 0 the per-type stride is auto-computed as OpConstantSizeOfEXT(<that element type>) → OpDecorateArrayStrideIdEXT. A "unified stride" means making every resource-heap per-type array advertise the same max(...) stride — the manual workaround documented in [spirv] spvDescriptorHeapEXT: heap-stride / load-width coupling for AS heap entries — index ≥ 1 mis-indexed without -spirv-resource-heap-stride #11231.
• Recommended approach: an opt-in boolean (e.g. -spirv-unified-descriptor-heap-stride) acting as a policy modifier on the arrayStride == 0 auto branch only (an explicit -spirv-resource-heap-stride N still wins). Redefining the stride-0 default to mean "unified max" is not advisable: it would over-stride the separate-heap topology (per-type heaps packed at sizeof(thatType)) and mis-index in the other direction — so the behavior must be opt-in.
• Emission construct: OpExtInst GLSL.std.450 UMax is not viable here (its result is not a constant and cannot be a decoration-Id operand). The portable construct is an OpSpecConstantOp max chain — Select(compare(a,b), a, b) folded pairwise over the per-type OpConstantSizeOfEXT ids, fed to OpDecorateArrayStrideIdEXT. Slang already emits OpSpecConstantOp with OpSelect and integer comparisons, so the machinery exists.
• Open gate / next action: one spirv-val/spec question must be confirmed before any code lands — whether OpSpecConstantOp may consume an opaque OpConstantSizeOfEXT operand and have its result used as an OpDecorateArrayStrideIdEXT id. If not, the feature isn't portably emittable and a host-pinned literal stride remains the only path. Holding for a maintainer design decision (descriptor-heap area owners) on the flag surface + this construct.

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

[jkwak-work]

@nv-slang-bot , I am not sure what option I have here.

one spirv-val/spec question must be confirmed before any code lands — whether OpSpecConstantOp may consume an opaque OpConstantSizeOfEXT operand and have its result used as an OpDecorateArrayStrideIdEXT id. If not, the feature isn't portably emittable and a host-pinned literal stride remains the only path.

It sounds like there isn't a better alternative, is there?
Can you clarify what I might be missing here?

[nv-slang-bot]

@jkwak-work — good news, and it changes the framing of my note: I dug into the gate against the SPIR-V validator Slang actually bundles (external/spirv-tools, the same code that runs under SLANG_RUN_SPIRV_VALIDATION), and the answer is yes — a symbolic-max stride is statically valid and portably emittable. You are not boxed into a hardcoded literal.

Q1 resolution (all three sub-parts clear, against the bundled validator at top-of-tree):

1. Can OpSpecConstantOp express a max? Yes. OpExtInst GLSL.std.450 UMax is ineligible (its result is not a constant, so it can't be a decoration <id>), but max(a,b) builds as the OpSpecConstantOp chain Select(UGreaterThan(a,b), a, b). ValidateSpecConstantOp (source/val/validate_constants.cpp:590) only Kernel-gates the convert/float/access-chain ops; integer OpSelect/comparisons fall through to success under Shader. Slang already emits OpSpecConstantOp + OpSelect/integer-compare elsewhere (slang-emit-spirv.cpp:3760-3784), so the machinery exists.
2. Can the operands be the opaque OpConstantSizeOfEXT sizes? Yes. OpConstantSizeOfEXT is classified as a constant (source/opcode.cpp:157, spvOpcodeIsConstant), so it is a valid OpSpecConstantOp operand. Its value being driver-deferred is a runtime concern, not a static-validation rejection.
3. Will the result be accepted as the OpDecorateArrayStrideIdEXT stride <id>? Yes. validate_annotation.cpp:362-395 requires only that the stride operand have a 32-bit int scalar result type, and it explicitly tolerates a non-foldable stride: "Even if spec constant, validation layers will test when frozen" (:378) — when the value can't be constant-folded it skips the zero-check and passes. This is the same operand slot the existing stride == 0 auto path already fills with OpConstantSizeOfEXT → OpDecorateArrayStrideIdEXT (slang-emit-spirv.cpp:7199-7217).

What I think you were missing — there are three portable options, not just "symbolic-max or a baked literal":

• (a) Host-pinned literal (-spirv-resource-heap-stride N, available today): works, but the value is fixed at compile time → you must recompile for any device whose descriptor sizes differ.
• (b) Symbolic max (the proposed unified mode): decorate each resource-heap per-type runtime array's ArrayStrideIdEXT with max(OpConstantSizeOfEXT(bufferDesc), OpConstantSizeOfEXT(imageDesc), …) via the OpSpecConstantOp Select chain. The driver resolves the real per-type sizes and the max when the pipeline is frozen → portable, no host plumbing, no recompile.
• (c) Specialization constant (SpecId): the app computes max(bufferDescriptorSize, imageDescriptorSize) from device properties and supplies it via VkSpecializationInfo at pipeline creation; decorate the stride with that spec-constant id. Portable without recompiling the SPIR-V, at the cost of the application owning the value. (Same validator path — a spec-constant stride id is explicitly anticipated.)

Recommendation: the opt-in unified mode via (b) is the cleanest "just works portably" default for a shared resource heap; (c) is the alternative if you'd prefer the application own the stride; (a) stays as the explicit override. (b) and (c) both solve the per-device-size portability problem that a baked literal cannot.

One honest caveat: the above confirms static validity against the bundled validator source — and the validator itself defers the final, frozen-value check to the runtime ("validation layers will test when frozen"). So a live Vulkan driver is the ultimate arbiter, which I can't exercise here. Worth a quick on-device sanity check of an emitted module before committing to (b) as the default.

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

[jkwak-work]

@nv-slang-bot
We definitely want the (b) option.
Please make a PR for this issue with the option (b).

[nv-slang-bot]

• Status: Draft PR opened — Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723 (Fixes #11718), held as a draft for maintainer review.
• Link: Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723
• Verdict: Implemented option (b) as an opt-in PROPOSAL — flag SPIRVUnifiedDescriptorHeapStride (-spirv-unified-descriptor-heap-stride). When set, every resource descriptor-heap runtime array advertises one shared ArrayStride = max(per-type OpConstantSizeOfEXT), built as an OpSpecConstantOp Select(UGreaterThan(a,b), a, b) chain (one memoized constant) and applied via OpDecorateId … ArrayStrideIdEXT. Explicit -spirv-resource-heap-stride N still wins, by construction. Samplers (separate heap) and acceleration structures (non-zero stride) are excluded. New tests/spirv/descriptor-heap-unified-stride.slang passes 4/4 (unified / no-flag control / explicit-override / single-type), all variants pass static SPIR-V validation.
• Next-action: Maintainer review of the proposed flag name + semantics; the PR stays a draft until then.
• Blocker: Honest caveat — the bundled spirv-tools validator confirms the decoration is structurally valid but defers the frozen-value check (is the chosen stride actually ≥ every per-type size at device time?) to runtime. A live Vulkan driver is the final arbiter; that could not be exercised here (no GPU in the build environment). The one issue static validation did catch — the ArrayStrideIdEXT operand must appear earlier in the binary than its target array — is fixed by reordering the deferred arrays after the shared max.

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

[nv-slang-bot]

Update — current PR status (this supersedes the earlier "held as a draft" comment above, which the bot cannot edit in place: HTTP 403 on the issue-comments edit endpoint).

• Status: Implemented in PR Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723 (Fixes #11718); opened as a draft, then promoted to ready-for-review by @jkwak-work. OPEN / MERGEABLE. Merge is maintainer/operator-gated (never the bot).
• Link: Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723
• Verdict: Opt-in flag -spirv-unified-descriptor-heap-stride (SPIRVUnifiedDescriptorHeapStride). When set, every image/buffer resource descriptor-heap runtime array advertises one shared, fixed ArrayStrideIdEXT = the canonical max(sizeof(image descriptor), sizeof(buffer descriptor)) from the SPV_EXT_descriptor_heap proposal, built as a memoized OpSpecConstantOp Select(UGreaterThan(a,b), a, b) chain over device-defined OpConstantSizeOfEXT sizes. The stride is non-adaptive — emitted regardless of which categories a shader references (a buffer-only shader still emits the full image-vs-buffer max), so two shaders sharing one host-packed heap can never disagree. The constant is emitted lazily before the first array it decorates (no finalize/reorder pass). Samplers (separate heap) and acceleration-structure entries (literal uint64 stride) are excluded.
• Refinement vs initial triage: setting BOTH -spirv-resource-heap-stride N and the unified flag is now a hard error — E57006 SpirvConflictingDescriptorHeapStrideOptions — rather than "explicit wins" (contradictory intent fails loudly).
• Tests: tests/spirv/descriptor-heap-unified-stride.slang 4/4 static (UNIFIED / DEFAULT control / CONFLICT diagnostic / SINGLE non-adaptive guardrail), plus descriptor-heap-unified-stride-runtime.slang (a -vk bindless COMPARE_COMPUTE) 1/1. spirv-val EXIT=0 for both entry points.
• Next-action: @jkwak-work re-review + CI on c2dc734; then maintainer merge (gated).
• Caveat: static spirv-val confirms structural validity; the device driver is the final arbiter of the device-defined descriptor sizes and the resulting frozen stride — not exercised end-to-end on hardware in CI (no GPU). The proposal's literal %void/Sampled=0 placeholder image is invalid for Vulkan (VUID-04656/-04657), so a spec-valid %float/Sampled=1 placeholder stands in; @csyonghe flagged in the PR for this deviation.

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

[nv-slang-bot]

This supersedes comment 4793075082 above — that one had stale test/status info and imprecise E57006 framing, and the bot cannot edit it in place (comment-edit is creator-bound but the fixer token 403s repeatably). Corrected, current status below.

• Status: Implemented in PR Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723 (Fixes #11718); opened as a draft, then promoted to ready-for-review by @jkwak-work. OPEN / MERGEABLE. Merge is maintainer/operator-gated (never the bot).
• Link: Add opt-in unified ArrayStride for SPIR-V resource descriptor heaps #11723
• Verdict: Opt-in flag -spirv-unified-descriptor-heap-stride (SPIRVUnifiedDescriptorHeapStride). When set, every image/buffer resource descriptor-heap runtime array advertises one shared, fixed ArrayStrideIdEXT = the canonical max(sizeof(image descriptor), sizeof(buffer descriptor)) from the SPV_EXT_descriptor_heap proposal, built as a memoized OpSpecConstantOp Select(UGreaterThan(a,b), a, b) chain over device-defined OpConstantSizeOfEXT sizes. The stride is non-adaptive — emitted regardless of which categories a shader references (a buffer-only shader still emits the full image-vs-buffer max), so two shaders sharing one host-packed heap can never disagree. The constant is emitted lazily before the first array it decorates (no finalize/reorder pass). Samplers (separate heap) and acceleration-structure entries (literal uint64 stride) are excluded.
• Refinement vs initial triage: the unified flag is mutually exclusive with a non-zero -spirv-resource-heap-stride — supplying both is a hard error (E57006 SpirvConflictingDescriptorHeapStrideOptions) rather than "explicit wins". The conflict gates precisely on SPIRVResourceHeapStride != 0, so an explicit -spirv-resource-heap-stride 0 selects the same default OpConstantSizeOfEXT path the unified flag modifies and is accepted (a valid 0 + unified combination — not an error).
• Tests: tests/spirv/descriptor-heap-unified-stride.slang — 4 static variants (UNIFIED / DEFAULT control / CONFLICT diagnostic / SINGLE non-adaptive guardrail). spirv-val (SLANG_RUN_SPIRV_VALIDATION=1) EXIT=0 for both entry points (computeMain, computeSingle). No runtime COMPARE_COMPUTE test: the runtime stack (slang-rhi) does not yet support VK_EXT_descriptor_heap, so a runtime comparison cannot exercise the unified-stride path (an earlier runtime test was added then removed at @jkwak-work's request for this reason).
• Next-action: docs for the option added on 3 surfaces (user-guide convenience-features + compiling API-options table + generated CLI reference); head is now 893f8cc2. The doc commits auto-dismissed @jkwak-work's APPROVE → PR is REVIEW_REQUIRED pending his re-approval of the doc work (not a substantive objection). Then CI-green + maintainer merge (gated).
• Caveat: static spirv-val confirms structural validity; the device driver is the final arbiter of the device-defined descriptor sizes and the resulting frozen stride — not exercised end-to-end on hardware in CI (no GPU). The proposal's literal %void/Sampled=0 placeholder image is invalid for Vulkan (VUID-04656/-04657), so a spec-valid %float/Sampled=1 placeholder stands in; @csyonghe flagged in the PR for this deviation.

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