-
Notifications
You must be signed in to change notification settings - Fork 244
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
Replace spirv_std::storage_class::X<T> with T/&mut T and #[spirv(x)] &T/&mut T. #443
Replace spirv_std::storage_class::X<T> with T/&mut T and #[spirv(x)] &T/&mut T. #443
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.
Looks hecking great! @hrydgard and I had a conversation in discord, path forward seems to be to make inputs be by-value, and then in a follow-up, do the annoyingly complex work of making outputs be returned via tuple or struct or whatever.
This comment has been minimized.
This comment has been minimized.
4c8c144
to
ff92d4e
Compare
@khyperia FWIW this is ready for a re-review, but I can't figure out what's wrong with the CI. |
I'm going to re-run and temporarily disable auto-merge |
Yeah, it was an issue with GitHub Actions, the PR passes. |
// FIXME(eddyb) should we just remove all 5 of these storage class | ||
// attributes, instead of disallowing them here? |
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.
Would there ever be a need to use these attributes in spirv-std
? If not, I agree that we should remove them.
This is my pre-#416 branch, I started this as part of #414, but only later realized I don't need it.It's easier than I expected because, once again, I was able to mostly reuse existing logic (attribute parsing in this case).As it's currently implemented, rules are:
&T
and&mut T
are allowed as entry parameter types, with explicit storage class attributes&mut MaybeUninitialized<T>
instead of&mut T
, but ideally we can use-> T
instead forOutput
&T
immutable but it should also check thatT: Freeze
T
defaults toInput
,&mut T
defaults toOutput
, and those storage classes cannot be explicitly specified#[spirv(...)]
attribute on the parameter, e.g. this line insky-shader
:UniformConstant
, andPushContant
storage classes only allow&T
(i.e. not&mut T
) typesPrivate
,Function
andGeneric
storage classes cannot be specified at allThis works and passes tests, but I'm opening it as a draft because it should wait on a decision regarding #416, especially around theOutput
storage class and whether we should use a->
style, support bundling them instruct
s etc.EDIT: updated to reflect PR changes, i.e.
Input
not taking references anymore.