[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)

[buzmeg]

Anybody know what the status of this is?

It's one of the big points of incompatibility preventing people from fully migrating off of GLSL.

[devshgraphicsprogramming]

Anybody know what the status of this is?

It's one of the big points of incompatibility preventing people from fully migrating off of GLSL.

AFAIK, not in development for DXC, probably in dev for Clang-HLSL. Already implemented in Slang.

I've been able to make my own BDA with vk::SpirvType and Inline Spir-V intrinsics, HOWEVER they only work for is_fundamental_v<T> (scalar and vector) and I've been banging the drum over and over again that if only this little issue (DXC not being able to figure out/annotate the offsets/layouts for a struct type T #6541) got fixed I'd be able to make BDA for all types.

I mean, heck, I even have atomics on my BDAs!
See our counting sort https://github.com/Devsh-Graphics-Programming/Nabla/blob/d37770f6dfab7f19de6c798ddd2c5a93256ee7ae/include/nbl/builtin/hlsl/bda/bda_accessor.hlsl#L39

Again I'm not a dev so they can probably tell you more about the roadmap

[s-perron]

AMD is working on an implementation. @danbrown-amd Can you provide an update?

[danbrown-amd]

I've circulated in-house an implementation of everything but the templated casts. (I've asked @greg-lunarg for clarification about how the alignment template parameter should show up in the output.) I'm hoping to get a PR out in 2024.