On reading built-in variables SubgroupEqMask, SubgroupGeMask, SubgroupGtMask,
SubgroupLeMask, and SubgroupLtMask, the AST expects 64-bit ints, while SPIR-V
is defined as vectors of 32-bit ints.
The declaration type has to be translated in the opposite direction.
Including spirv and AST tests
Also increase size of TBuiltInVariable bitfields since we've now exceeded 127
and add a static_assert to make this easier to find next time it happens!
Closes#1735
GlslangToSpv.cpp
- minor formatting cleanup
BaseTypes.h
- minor formatting cleanup
- add subgroup builtins to GetBuiltInVariableString
(was resulting in "unknown built-in variable" messages in test output)
Initialize.cpp
- better naming and re-use of strings for subgroup builtin variable declarations
- define subgroup builtin variables in ray-tracing shaders
intermOut.cpp
- add handling of the EOpSubgroupParition* variables
(was resulting in "ERROR: Bad aggregation op" messages in test output)
Update test results.
This is a better place for it logically, since it is not specific to
glsl->spirv translation. And in a future change I want to use it outside
of glslangtospv.
This is an alternate fix for the issue described in commit be63facd, whose
solution didn't work if there were non-trivial operations involved in computing
a constant initializer which caused the 'constant unfolding' code to kick in
(addConstantReferenceConversion). Instead, this change does the 'unfolding'
later in createSpvConstantFromConstUnionArray. If a reference-type constant has
survived that long, then folding is already done, this must be a 'real' (inside
a function) use of the constant, and it should be safe to unfold and apply the
bitcast.
Last year we changed 'volatile' to also act as 'coherent', but when I
resolved the memory model changes against that change I missed handling
volatile in a couple places that we check for coherent. There was also
a place in post-processing that acted as if the volatile memory access
flag has a literal number associated with it, when it doesn't.
Without this commit, if the XfbStride was explicitly set, the
decoration was added twice on the shader.
v2 (changes after Jonh Kessenich first review)
* Simplified by just removing the firs assignment
* Removed assert
including SPV generation using SPV_EXT_fragment_invocation_density.
This is an alias of the functionality in SPV_NV_shading_rate, and thus in some
cases we can only have one set of the tokens present (switch statements), so
we have picked the EXT version. This required updating the expected test
results for SPV_NV_shading_rate.
Also updated the known-good for spirv-headers so that the validator in
spirv-tools knows about the new extension.
