DirectXShaderCompiler
DirectXShaderCompiler copied to clipboard
[SPIR-V] vk::ext_capability can only tag vk::SpirvType aliases and typedefs, not other types
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
Seems that https://github.com/microsoft/hlsl-specs/issues/191 and https://github.com/microsoft/hlsl-specs/pull/270 didn't foresee such a use in their design.
I'm also quite suprised that
[[vk::ext_capability(spv::CapabilityRayQueryKHR)]]
using RayQueryKHR = vk::SpirvOpaqueType<spv::OpTypeRayQueryKHR>;
doesn't want to compile for me either