[SPIR-V][Feature Request] Implement Buffer Pointers in HLSL With vk::BufferPointer

[Keenuts]

The proposal for BufferPointer is now in the accepted state.
So we should now be able to start implementation on this.

https://github.com/microsoft/hlsl-specs/blob/main/proposals/0010-vk-buffer-ref.md

Adding this issue to track the SPIR-V side of the work.

[devshgraphicsprogramming]

Here's the deal, given that Proposal 0011 is merged, I could implement proposal 0010 as a pure header-only library.

Provided this issue is fixed
#5784

[devshgraphicsprogramming]

I'm actually quite close to getting it working, blocked by #6541 though

[s-perron]

I've looked at this more closely. We might be able to implement something similar to the proposal using inline spir-v, but it cannot implement is properly. The main reason is the get() is suppose to return a reference, but that cannot be expressed in HLSL at this time. When references are added to HLSL properly, then we could implement it in inline spir-v.

I don't think we should wait until them.

The reason this is such a big deal is that if you cannot return a reference, then the number of operations you will need to define in inline spir-v grows to a huge number. You will have to define specific load and store instruction. You'll have to redefine all of the atomic operations. Just in general the syntax will not be as clean.

We still need to do a builtin definition of the class to be able to get the reference semantics right.

[Tobski]

Hmm, the only thing I'm wondering here though is that if that proposal relies on references, do we need an implementation of references proper to actually make that work anyway? Or do you think it's possible to implement that proposal without doing so?

[s-perron]

Good question. I do not think that is a problem because we have precedent for having builtin functions that return a reference. It might not be described that way, but that is what it is.

For example RWStructuredBuffer::operator[] really returns a reference. The same for any operator[]. We will essentially implement the same concept.

[devshgraphicsprogramming]

The reason this is such a big deal is that if you cannot return a reference, then the number of operations you will need to define in inline spir-v grows to a huge number. You will have to define specific load and store instruction. You'll have to redefine all of the atomic operations. Just in general the syntax will not be as clean.

@s-perron its worse thank you think, you can't define a reference with current inline SPIR-V hence my request for #6578 (which follows/supersedes my #5675 request)