[SPIR-V] Requesting useless OpCapability StoragePushConstant16 when using vk::BufferPointer

[Goshido]

Description
I was trying to use latest vk::BufferPointer pattern instead vk::RawBufferLoad. I only modified single shader. C++ code is the same. VVL with sync validation and GPUAV does not report any problems. Here what I got so far.

I see the requirement to use OpCapability StoragePushConstant16 in SPIR-V which does not make any sense for this shader scope. ⚠️This feature is not used but forces the developer to request this feature from VkDevice. It automatically limits available devices for application and produces VVL errors. Many downsides without any benefits.

Steps to Reproduce
Compile this shaders: preprocess.zip

with DXC flags:

-HV 2021
-spirv
-fvk-use-dx-layout
-fspv-reduce-load-size
-fspv-target-env=vulkan1.1spirv1.4
-ffinite-math-only
-enable-16bit-types
-WX
-O3
-E VS
-T vs_6_10
-Fo <output.hlsl.spv>
<source.hlsl>

Expected

• vk::BufferPointer must correctly extract uint16_t values
• no require OpCapability StoragePushConstant16 in SPIR-V
• no compile warnings
• 🙏please fix this issue #8543 - it causes a lot of friction when debugging with RenderDoc/Nsight/Aftermath

Environment

• git submodule update --init has been invoked before build
• hctbuild build parameters: -official -rel -x64 -vs2026 -speak-up -no-dxilconv -spirv -lto
• Visual Studio 2026 Community components were up to date.
• Windows 11 Pro (25H2, Build 26200.9278)
• dxc.exe v1.9.2607.10104 executable, commit SHA-1 1b949a448e4c9e821f010c488defebfbb1a50b27

[Maraneshi]

When the CapabilityVisitor visits a BufferPointer<T>, it wants to add the capabilites necessary for the type T it points to, but passes the storage class of the pointer for that check, see code here. It should instead pass spv::StorageClass::PhysicalStorageBuffer.

The struct type visit below to add the capability for 16-bit types in storage buffers (StorageUniformBufferBlock16/StorageBuffer16BitAccess) uses the "interface type" of the struct instead of the storage class, so one would need to double check that this interface type is correct and this capability is added instead of StoragePushConstant16.

Edit: Unfortunately it's not quite as simple to fix. The BufferPointer itself does actually pass the correct storage class unlike what I guessed, but it's all associated recursively with the struct containing the push constants, which themselves are also accessed via a SPIR-V pointer. The check SpirvType::isOrContainsType<NumericalType, 16>(structType) does actually succeed for the push constants because it does follow pointers. Maybe that function needs to return whether that type is reached via a pointer or not and then add capabilities as needed? We also need to make sure that both BufferPointer<StructContainingFP16> and BufferPointer<float16_t> and equivalent RawBufferLoad variants add the correct caps.

Edit2: I tried a fix, but it seems hacky and unfortunately my caps bits are taken away again by the "trim capabilities" pass, which I do not understand at all how to modify.

To make it easier for people who actually know what they're doing, here's the HLSL test file I made:

#ifndef TESTCASE
#define TESTCASE 1
#endif

struct TestStruct {
    float16_t f;
};

struct TestPush {
#if TESTCASE==1
    vk::BufferPointer<float16_t> buffer;
#elif TESTCASE==2
    vk::BufferPointer<TestStruct> sbuffer;
#else
    uint64_t bda;
#endif
};
[[vk::push_constant]] TestPush push;

float main(void) : SV_Target0 {
#if TESTCASE==1
    float16_t t = push.buffer.Get();
#elif TESTCASE==2
    float16_t t = push.sbuffer.Get().f;
#elif TESTCASE==3
    float16_t t = vk::RawBufferLoad<float16_t>(push.bda);
#elif TESTCASE==4
    float16_t t = vk::RawBufferLoad<TestStruct>(push.bda).f;
#elif TESTCASE==5
    float16_t t = vk::BufferPointer<float16_t>(push.bda).Get();
#elif TESTCASE==6
    float16_t t = vk::BufferPointer<TestStruct>(push.bda).Get().f;
#endif
    return t;
}

Compiled with -E main -T ps_6_6 -spirv -enable-16bit-types, all 6 cases should produce OpCapability PhysicalStorageBufferAddresses, StorageBuffer16BitAccess, Float16 (cases 3 to 6 also Int64) and not StoragePushConstant16 nor StorageInputOutput16, in addition to OpExtension "SPV_KHR_16bit_storage" and "SPV_KHR_physical_storage_buffer".

Edit3: Last findings before I gave up completly:
I tried making the CapabilityVisitor add the correct caps/exts as listed above by modifying SpirvType::isOrContainsType to return whether a type was contained directly or only via a pointer indirection. This resulted in pretty gnarly code that had to add the caps in multiple places since it affects both structs and pointers to non-structs and until now StorageUniformBufferBlock16/StorageBuffer16BitAccess was only ever added based on the "interface type" of a struct. I wonder if it would be possible and much easier to just do the same thing as for StorageInputOutput16 instead: simply checking the storage class once we reach the underlying float16/int16 type. Of course I have no insight into what might break if we no longer check the struct interface type.

Unfortunately it is indeed the spirv-opt "trim capabilities" pass that removes StorageInputOutput16 later on even though I add it with the CapabilityVisitor. This does not happen for a roughly equivalent shader compiled by glslang (example), so something about the SPIR-V DXC outputs must be off or it's a bug in spirv-opt. It's also weird that it does not remove the erroneous StoragePushConstant16 cap from our DXC output.