-
Notifications
You must be signed in to change notification settings - Fork 193
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
[hlsl-out] More matCx2
fixes
#1989
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.
This doesn't handle the case of arrays of matrices; see my comments on the code.
We should probably remove the reference to #1837 in src/back/hlsl/mod.rs
.
…ices and also write it on nested arrays of matrices
38b44c3
to
fbe927c
Compare
Fixed |
matCx2
as global uniformmatCx2
fixes
47b41c4
to
8e678e6
Compare
@jimblandy this should now be good to go. I think we have all our I added some more comments - I hope they are helpful. |
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.
I need to look at this again tomorrow. Comments thus far, nothing too serious:
It might be good to add __mat
, __get
, and __set
to the list of reserved prefixes passed to Namer::reset
in `hlsl::Writer::reset.
It might be worthwhile going though help.rs
and similar code to look for other prefixes we've neglected to tell Namer
to avoid. So far I've found ret_
(for the typedefs generated by write_wrapped_constructor_function
) and Construct
.
Or, maybe just start all generated names with __
, and then only warn Namer
about that?
Regarding the Namer, I'd say we go for
since WGSL already doesn't allow identifiers that start with two underscores. |
Okay - having thought on this a little more, I'm inclined to merge this as-is for the moment. But the current design (which predates this PR) feels focused on identifying special cases. In the longer term, we need to look hard for some useful generalizations, that will make it easier to see that all the cases are being covered. |
fixes #1837