[0010] Define vk::BufferPointer pointee atomics

[llvm-beanz]

Which document does this relate to?
Proposal 0010 - vk::BufferPointer

Describe the issue you see with the spec
vk::BufferPointer::Get returns a reference. Can this reference be used with atomics?

Additional context
See comment here

[devshgraphicsprogramming]

I think what me, @Ipotrick and @Dolkar are getting at is more along the lines, can the reference be used as an inline-spirv function argument declared with [vk::ext_reference]

I don't think the ability to just be able to pass the immediate result of Get to InterlockedAdd and friends will make us happy.

[llvm-beanz]

@devshgraphicsprogramming, that's completely separate from what this issue is tracking. The intent of this issue is to track defining how vk::BufferPointer will interact with the current atomic operations. How it will interact with other Vulkan extensions is something we should track and discuss elsewhere.

I may have confused you by the comment that I linked to, but I think there are multiple issues here that need to be tracked and discussed separately.

[llvm-beanz]

@greg-lunarg, I'm going to put this one on my plate at least to start with. It relates to #89, and I have some questions I want to sort out relating to the address spacing of the references these APIs will return.

[devshgraphicsprogramming]

Can we make it the job of SPIR-V intrinsics (proposal 0011) to provide the atomics?

[s-perron]

I think what me, @Ipotrick and @Dolkar are getting at is more along the lines, can the reference be used as an inline-spirv function argument declared with [vk::ext_reference]

Yes it can. We could try calling that out explicitly.

I don't think the ability to just be able to pass the immediate result of Get to InterlockedAdd and friends will make us happy.

What more do you need? Is this because you want to pass the members. You should be able to do write:

InterlockedAdd(bufferPointer.Get().x, 1, orig);

This will do an atomic operation on the member. From a language perspective, this falls out natually because the dot operation on an lvalue returns another lvalue. We should call this out explicitly, and make sure we have a test for it in the implementation.