microsoft / microsoft/DirectXShaderCompiler
[SPIR-V] vk::ext_capability can only tag vk::SpirvType aliases and typedefs, not other types
@luciechoi is already working on this.
Since Apr 17, 2026.
- Dominant language
- C++
- Stars
- 3.7k
- Forks
- 900
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 44
Description
Description
I have a templated struct (nbl::hlsl::bda::__ptr<T>) that uses vk::SpirvType internally to declare a PhysicalStoragePointer of another type T.
I put [[vk::ext_capability(spv::CapabilityStorageBuffer8BitAccess)]] in the typedef for a __ptr<uint16_t> (is supposed to be uint8_t later), and I expect the usage of that type to propagate the capability.
My argument for why I need extensions and capabilities to propagate is because for example CapabilityStorageBuffer8BitAccess is a specific capability of using a (u)int8 AND PhysicalStorageBuffer storage class, so I'd have to manually declare a fairly complicated SpirvType (two nested) just to be able to stick the capability on it.
This gets especially annoying for capabilities/extensions dealing with images, as an inline SPIR-V declaration for a combined image sampler or similar can be a chain of 4-5 SpirV types.
Steps to Reproduce
My own Godbolt instance with a few more headers: https://tinyurl.com/ydhdncw3
Can produce preprocessed full source and make a repro on godbolt with vanilla DXC
Actual Behavior
No OpCapability CapabilityStorageBuffer8BitAccess emitted
Environment
- DXC version more or less commit f810e92e72abd4e7e6301ad6d44e34ea57ff017d
- Host Operating System Windows
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.