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] The layout of the pointee buffer is not well defined. #306

Open
s-perron opened this issue Aug 23, 2024 · 2 comments
Open

[0010] The layout of the pointee buffer is not well defined. #306

s-perron opened this issue Aug 23, 2024 · 2 comments
Labels
active proposal Issues relating to active proposals enhancement New feature or request needs-triage

Comments

@s-perron
Copy link
Collaborator

s-perron commented Aug 23, 2024

Which document does this relate to?
https://github.com/microsoft/hlsl-specs/blob/9c42e278961dbf5b77d7d18b1e7ba7f6c0856154/proposals/0010-vk-buffer-ref.md

Describe the issue you see with the spec

In the Buffer Pointer Pointee Buffer Layout section, it says:

The pointee of a vk::BufferPointer is considered to be a buffer and will be laid out as the user directs all buffers to be laid out

The problem is that I am not sure why type of buffer this is referring to. I assume it refers to structured buffers, but it could be a constant buffer, which are laid out differently. See the SPIR-V documentation for how different types are laid out.

Note that the types have to follow the standard storage buffer layout rules.

It is also worth considering the conversations in microsoft/DirectXShaderCompiler#4924.

Additional context

The layout for the vk::RawBuffer* have been an issue for people, and we should avoid the same mistakes with vk::BufferPointer. The layout needs to be well documented, and tested.

@s-perron
Copy link
Collaborator Author

@cassiebeckley Could you please look into this?

@devshgraphicsprogramming
Copy link

devshgraphicsprogramming commented Aug 23, 2024

Any device that has the non-uvec2 variant (uint64_t) of Buffer Device Address, is extremely likely to have Scalar Layout as a feature as well.

P.S. SSBOs can be laid out as UBOs as well (and scalar laid out too), so there's at least 3 different possible layouts that can be applied there.

P.P.S. -fkv-use-scalar-layout makes all HLSL StructuredBuffers have a scalar layout, I'd just dodge the bullet and require RawBufferPointers to always be scalar instead of having a headache of supporting two layouts in the codegen for that.

@damyanp damyanp added the enhancement New feature or request label Sep 4, 2024
@damyanp damyanp moved this to For Google in HLSL Triage Sep 4, 2024
@llvm-beanz llvm-beanz added the active proposal Issues relating to active proposals label Nov 12, 2024
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 enhancement New feature or request needs-triage
Projects
Status: No status
Status: For Google
Development

No branches or pull requests

4 participants