Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0010] Define casting rules for vk::BufferPointer<T,A> #44

Closed
llvm-beanz opened this issue Apr 14, 2023 · 5 comments · Fixed by #51
Closed

[0010] Define casting rules for vk::BufferPointer<T,A> #44

llvm-beanz opened this issue Apr 14, 2023 · 5 comments · Fixed by #51
Labels
active proposal Issues relating to active proposals

Comments

@llvm-beanz
Copy link
Collaborator

Which proposal does this relate to?
0010-vk-buffer-ref.md

Describe the issue or outstanding question.
We need to define the casting rules and casting operators for vk::BufferPointer<T,A> objects. Completely off the top of my head, I think it would be beneficial to have a vk::pointer_cast<>() casting operator and enforce the legality of casts through the operator.

Open to other suggestions and explorations.

Additional context
See initial review discussion.

@llvm-beanz llvm-beanz added the active proposal Issues relating to active proposals label Apr 14, 2023
@s-perron
Copy link
Collaborator

If we use the idea for aliasing in #42 (comment). I would have no problem with adding a pointer cast.

There is not type based aliasing in spir-v, so this should not cause any subtle and dangerous interactions because of the different types.

If we go with @greg-lunarg's idea to add type based aliasing, then we will have to think carefully about this. My view would be to disallow it.

@devshgraphicsprogramming

Can we re-use syntax we're all familiar with?

vk::BufferPointer<uint,4> pU;
auto pF = reinterpret_cast<vk::BufferPointer<float,4>>(pU);

Then pointer_cast<T,A> could just be a templated function for brevity.

Also if pointer_cast or reinterpret_cast allowed for taking uint64_t as a template parameter or function argument, then we could have support for "manufacturing pointers from uint64_t" but without the danger of implicitly making null pointers.

@BeastLe9enD
Copy link

Lets say I have a vk::BufferPointer that points to an uint array. Will it be possible to have a vk::BufferPointer<uint[]> and then use ptr.Get()[idx] to get the uint at index idx?
The reason I ask the question right here is because if that is not possible, I think it is very important to be able to cast from uint64_t to vk::BufferPointer<T, A>.

@greg-lunarg
Copy link
Contributor

greg-lunarg commented Apr 21, 2023

Based on requests from @natevm et al, I propose that we support a mechanism to cast from a uint64_t. The syntax would need to be able to specify the type that is being created. My preference would be the simple vk::BufferPointer<T,A>(u).

@s-perron
Copy link
Collaborator

Lets say I have a vk::BufferPointer that points to an uint array. Will it be possible to have a vk::BufferPointer<uint[]> and then use ptr.Get()[idx] to get the uint at index idx? The reason I ask the question right here is because if that is not possible, I think it is very important to be able to cast from uint64_t to vk::BufferPointer<T, A>.

You should be able to put the array in a struct, and then have a pointer to that struct.

struct T {
  uint[];
}

vk::BufferPointer<T, A>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
active proposal Issues relating to active proposals
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants