[Feature Request] [SPIR-V] [Proposal 0011] `vk::addrof(v)` to obtain an `OpTypePointer` to a variable and deprecate `[vk::ext_reference]`

[devshgraphicsprogramming]

Is your feature request related to a problem? Please describe.

When writing inline SPIR-V intrinsics in HLSL one needs to choose between making an input argument T, [vk::ext_reference] T or vk::SpirvType.

Its not well documented what ext_reference actually turns into but from my experience it seems to be and OpTypePointer to the actual argument invoked.

This makes it problematic to write an intrinsic signature thats supposed to work both with T& and arbitrary vk::SpirvType, for example OpAtomicIAdd .

If you write

template<typename T>
[[vk::ext_instruction]]
T atomicIAdd([[vk::ext_reference]] T ptr, ...memory semantics... , T value);

then it will work on RWStructuredBuffer variables, but won't work on user-defined BDA pointers (or any pointers).

But if you write

template<typename T, typename P>
[[vk::ext_instruction]]
T atomicIAdd(P ptr, ...memory semantics... , T value);

then it will only work on vk::SpirvType defined pointers.

Which wouldn't be too bad, except that you can't get a pointer/access-chain to any variable you like.

Describe the solution you'd like

A way to obtain an OpTypePointer for a given variable (basically a hidden &/addrof)

Also a way to obtain an OpType result id, because some instrinsics like OpDecorate or OpMemberDecorate need to be fed the type's %result_id as an argument, its unclear to me how to achieve that with the current mapping of.

[[vk::ext_instruction(%opcode%)]]
%result_type% intrinsicHLSLName(arguments...);

Describe alternatives you've considered

Just generating an overload, but that makes the compiler confused with ambiguity.

Additional context

Trying to generate all Types and Operations from SPIR-V Headers.

Also implement Prop 0010.

[devshgraphicsprogramming]

Here's what I tried in the meantime to return me a vk::SpirvType<OpTypePointer,StorageClass,T>

OpAccessChain with no Indices

• cannot be used for types that aren't composite
• fails with an ICE regarding a cast https://godbolt.org/z/M3ra87ro8

OpBitcast with a [[vk::ext_reference]] input casting to identical type

• fails to observe side effects on stores because of aliasing spirv-opt doesn't account for
• fails to compile on loads because something something "isn't a Logical Pointer"

Conclusion

There's nothing in SPIR-V I can use, I need a dedicated addrof. However that addrof needs to return a certain type....

The bugs? What could be happening?

The answer is simple, it seems that DXC is not-deduplicating the Op.....Type declarations.

and in my simple case here https://godbolt.org/z/M3ra87ro8

I'm getting two result IDs that declare a pointer to a uint32_t with the Workgroup storage space.

I think this behaviour might be the underlying cause for:

• [SPIR-V] RawBufferStore still trips up on missing member offsets #6554, [SPIR-V] [Proposal 0011] SPIR-V Type for a PhysicalStorageBuffer class OpTypePointer fails to compile because of missing offsets for a struct #6541, [SPIR-V] Problem loading struct with vk::RawBufferLoad. #4924
• [SPIR-V] Fix bug using Texture2D with alias template for SpirvType #6498

It kinda seems like the type-cache needs to be unified for the SPIR-V codegen, and regular HLSL types need to know what their SpirvType or SpirvOpaqueType is.

Or alternatively some legalization pass to dedup types.

[sudonatalie]

Requests for new HLSL language features (including Vulkan-specific attributes) now fall under the scope of the microsoft/hlsl-specs repository. Please consider submitting a proposal there instead.

[devshgraphicsprogramming]

Requests for new HLSL language features (including Vulkan-specific attributes) now fall under the scope of the microsoft/hlsl-specs repository. Please consider submitting a proposal there instead.

What are you planning to do about the fact that the apirv types don't deduplicate with the built-inones which makes it impossible to truly use prop 0011?