-
Notifications
You must be signed in to change notification settings - Fork 250
Fix Location calculation for arrays in entrypoint interface #513
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your PR! This looks good to me, can you also add two tests? One to ensure that the behaviour works, and one that generates the invalid entry param type
error? You can see similar tests in tests/ui
.
c7ab407
to
386e7dd
Compare
…ted rust-gpu Signed-off-by: Arc-blroth <[email protected]>
386e7dd
to
2ea927e
Compare
Signed-off-by: Arc-blroth <[email protected]>
Sorry for taking so long, but I've updated to HEAD and added a test for fixing array locations. The CI seems to be failing because of commits that don't have any relationship to this PR, but I tested this PR and it works locally. |
… fix/array_locations
Signed-off-by: Arc-blroth <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just adding a note to our future selves that this is incomplete, the vulkan spec says:
64-bit three- and four-component vectors consume two consecutive locations.
so we'll need to fix that too eventually (not needed in this PR).
Closing this for inactivity, if you'd like to revive this, please do! |
This PR fixes the calulation for Location decorations on array entrypoint parameters.
Both Vulkan (spec) and MLSL (page 44 of the spec) specify that array elements must take up consecutive locations, one for each element. Currently however, rust-gpu will always allocate 1 Location per entrypoint parameter, meaning that this code (playground link):
will generate invalid SPIRV:
since data and more_data have overlapping locations.
I'm not exactly that familiar with rustc and rustc_codegen_spirv, so there might be a better way to tell if an entrypoint parameter maps to a SPIRV array type than inspecting the generated type - please review :)