[Feature Request][SPIRV] RawBuffer<T>(uint64_t) which is the result_id of OpBitcast

[devshgraphicsprogramming]

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

We need a fix to #4983 before the heat death of the universe.

Describe the solution you'd like

RawBuffer<T>(addr) to return a result_id of OpBitcast %_ptr_PhysicalStorageBuffer_T %addr

Basically everything that RawBufferLoad<T> does, with the OpLoad trimmed off.

Describe alternatives you've considered

Doing a whole bunch of inline SPIR-V with hand-allocated type numbers but I don't seem to be able to declare an %_ptr_PhysicalStorageBuffer_int = OpTypePointer PhysicalStorageBuffer %int properly and then the OpBitcast to use the declared type.

This is what the SPIR-V looks like

         %22 = OpAccessChain %_ptr_PhysicalStorageBuffer_int %19 %int_0 %int_2
         %27 = OpAtomicIAdd %int %22 %uint_1 %uint_0 %int_69

for GLSL for simple types

#version 460
#extension GL_EXT_buffer_reference : enable

layout (location = 0) out vec4 fragColor;

struct Test {
    vec4 mem1;
    float mem2; 
    int mem3;
}; 

layout (buffer_reference, buffer_reference_align = 4u) buffer Test_r
{
    Test value;
};

layout (set = 0, binding = 0) uniform ConstantBuffer
{
    Test_r t;
};

void main()
{
	atomicAdd(t.value.mem3,69);
	fragColor = vec4(0.4, 0.4, 0.8, 1.0) + t.value.mem2;
}

Additional context

[devshgraphicsprogramming]

It really seems like having a RawBuffer<T>(addr) or RawPointer<T>(addr) would be more useful than the two separate load and store intrinsics, because then I could just slap it into my own inline SPIR-V for OpLoad, OpStore and OpXAtomic

and maybe it would solve some weird issues like #5641

[sudonatalie]

In this repository we are only addressing issues related to compilation of HLSL. Requests for new language features, including new Vulkan-specific intrinsics, should go through the HLSL Feature Proposal Process in microsoft/hlsl-specs. Please consider submitting a proposal there to have this request reviewed.

[s-perron]

We need a fix to #4983 before the heat death of the universe.

Please be respectful. We are contributing to an open source project, and you get the benefits without paying. We have our own set of priorities that will not always align with yours.

You will be able to get this functionality with the vk::BufferPointer proposal. We want to be careful we do not define a feature too close to the spir-v it generates. In the language of C/C++ style languages, you want an l-value of some type from a uint64 value that represents the address. You can do that by creating the bufferpointer from the uint64_t, and then using Get().

[devshgraphicsprogramming]

I've managed to wrangle exactly (minus the access chains and loading of aggregate types directly #6541 ) what I wanted here out of Proposal 0011, great thanks to Prop 0011 authors.