KhronosGroup/SPIRV-Registry

Better define externally visible shader Storage Classes (OpTypeBool)

Opened this issue · 1 comments

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

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.