Illegal to declare OpTypeBool variables as UniformConstant for OpenGL?
rdb opened this issue · comments
The spec says this about OpTypeBool:
If they are stored (in conjunction with OpVariable), they can only be used with logical addressing operations, not physical, and only with non-externally visible shader Storage Classes: Workgroup, CrossWorkgroup, Private, Function, Input, and Output.
Does this imply that it is not possible to declare a global UniformConstant boolean variable? That would imply that declaring a uniform bool in a SPIR-V shader targeting OpenGL is illegal, which surely cannot be the intent?
PS. If this is not the right place for filing issues against the SPIR-V specification, let me know and I will file it elsewhere.
Related to KhronosGroup/SPIRV-Tools#3387
I think this is an oversight, that the rule is Vulkan specific and not allowing for OpenGL's usage of a uniform bool in GLSL.
Any movement towards a resolution on this issue?
I have encountered this too. Converting the bool to int fixes this but it would be nice to solve this the right way
Allowing the bool type in the UnifromConstant storage class was intended to be allowed. This was clarified with the SPIRV-Tools maintainers as well. This will be resolved in near future SPIR-V revision.
This one is also hitting me, when using a bool inside a vertex in/out interface block. Any word on when/how this will get fixed?
This one is also hitting me, when using a bool inside a vertex in/out interface block. Any word on when/how this will get fixed?
GLSL does not allow bool input / output variables. Check 4.3.4 and 4.3.6 sections of the spec
It seems that the only allowed in/out variables are built-in variables, like gl_FrontFacing.
I did not know this either and i just found out :)
We believe the SPIRV-Tools PR addressed this. Please let us know if it is not sufficient.
@alan-baker Was the spec changed? Or is SPIRV-Tools deliberately acting out of spec since the change?
There is no spec at the moment, but we agree for GL is should be allowed. Any spec change will be (even) slower. So if the tools are unblocking your progress here that's a good start.
Yes, thank you, it's very helpful. But it would still be good that the SPIR-V spec is eventually changed so that it's also valid according to the letter of the spec.
It will be in the next revision of the SPIR-V specification.
The new revision of the specification has been published and fixed this, so closing.
See Revision 3 of SPIR-V 1.6 at https://registry.khronos.org/SPIR-V.