DirectXShaderCompiler icon indicating copy to clipboard operation
DirectXShaderCompiler copied to clipboard

[SPIR-V] vk::ext_capability can only tag vk::SpirvType aliases and typedefs, not other types

Open devshgraphicsprogramming opened this issue 1 year ago • 1 comments

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