On Monday, March 14, 2016 5:23:44 PM PDT Jason Ekstrand wrote: > On Sun, Mar 13, 2016 at 6:08 PM, Kenneth Graunke <[email protected]> > wrote: > > > We want to use interface_type, not vtn_var->type. They're normally > > equivalent, but for geometry/tessellation per-vertex interface arrays, > > we need to unwrap a level. > > > > Otherwise, we tried to iterate a structure members but instead used > > an array length. If the array length was longer than the number of > > fields in the structure, we'd crash. > > --- > > src/compiler/nir/spirv/vtn_variables.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/compiler/nir/spirv/vtn_variables.c > > b/src/compiler/nir/spirv/vtn_variables.c > > index 31bf416..1628042 100644 > > --- a/src/compiler/nir/spirv/vtn_variables.c > > +++ b/src/compiler/nir/spirv/vtn_variables.c > > @@ -923,7 +923,7 @@ var_decoration_cb(struct vtn_builder *b, struct > > vtn_value *val, int member, > > vtn_var->var->data.explicit_location = true; > > } else { > > assert(vtn_var->members); > > - unsigned length = glsl_get_length(vtn_var->type->type); > > + unsigned length = glsl_get_length(val->type->type); > > > > Good catch. What I think we really want here though is a "without_array" > helper. I'm not a huge fan of grabbing the type from the value because > that comes in from the client and I don't really trust it.
Hmm...okay. I suppose that would work, because vtn_var->members existing means that it's a struct...or array of structs. (I was afraid that we'd have to replicate the logic for deciding whether it's a normal varying array, or arrayed-interface...but I guess we don't...) --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
