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

Better define externally visible shader Storage Classes (OpTypeBool) #161

Open
sjfricke opened this issue Aug 18, 2022 · 1 comment
Open

Comments

@sjfricke
Copy link

sjfricke commented Aug 18, 2022

tl;dr - It would be nice to have a more consistent knowledge where OpTypeBool are allowed


in OpTypeBool it says

only with non-externally visible shader Storage Classes: Workgroup, CrossWorkgroup, Private, Function, Input, and Output.

but other Storage Classes such as Generic, CallableDataKHR, etc would also be "non-externally visible"

Also it seems that according to spirv-val the BuiltIn decoration also matters if it is "external", but I can't find that wording anywhere in the spec

Last thing, It also says

they must only be used with logical addressing operations, not physical

but is that suppose to just mean anything without OpMemoryModel Logical as the spec doesn't define any operations that are logical, just the model

@sjfricke sjfricke changed the title Better define externally visible shader Storage Classes Better define externally visible shader Storage Classes (OpTypeBool) Aug 18, 2022
@Tobski
Copy link
Contributor

Tobski commented Aug 19, 2022

I suspect there's a slightly broader issue here because right now you can technically do weird things like defining OpTypeVoid variables in a buffer or declaring an OpTypeImage the Output storage class - there's absolutely nothing banning this AFAICT. If you actually attempted to do that I'm fairly sure at least some vendor compilers would fall over, and in any case it's not clear what the behavior would be. I've raised a discussion internally about banning non-concrete types from any storage classes except Private, Function, and UniformConstant - we'll see how that goes.

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

No branches or pull requests

2 participants