spirv: Handle patch decorations up-front
authorJason Ekstrand <jason.ekstrand@intel.com>
Thu, 12 Jan 2017 02:04:57 +0000 (18:04 -0800)
committerJason Ekstrand <jason.ekstrand@intel.com>
Thu, 12 Jan 2017 18:41:34 +0000 (10:41 -0800)
commit27a1c7ffbdd7d7a8fd1240413446c1172752d93b
tree19dc4e58a0da392f9b1ba8de3f4d29282a5c0832
parent1e41d7f7b0855934744fe578ba4eae9209ee69f7
spirv: Handle patch decorations up-front

Once again, SPIR-V is insane... It allows you to place "patch"
decorations on structure members.  Presumably, this is so that you can
do something such as

out struct S {
   layout(location = 0) patch vec4 thing1;
   layout(location = 0) vec4 thing2;
} str;

And have your I/O "nicely" organized.  While this is a bit silly, it's
allowed and well-defined so whatever.  Where it really gets interesting
is when you have an array of struct.  SPIR-V says nothing about not
allowing you to have those qualifiers on the members of a struct that's
inside an array and GLSLang does this.  Specifically, if you have

layout(location = 0) out patch struct S {
   vec4 thing1;
   vec4 thing2;
} str[2];

then GLSLang will place the "patch" decorations on the struct members.
This is ridiculous there is no way that having some of them be patch and
some not would be well-defined given that patch and non-patch outputs
are in effectively different storage classes.  This commit moves around
the way we handle the "patch" decoration so that we can detect even the
crazy cases and handle them.

Fixes: dEQP-VK.tessellation.user_defined_io.per_patch_block_array.*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/compiler/spirv/vtn_variables.c