On Thu, 2016-07-07 at 20:12 -0700, Jason Ekstrand wrote: > > On Jul 7, 2016 7:47 PM, wrote: > > > > > > On Jul 7, 2016 9:59 AM, "Kenneth Graunke" <kenn...@whitecape.org> > wrote: > > > > > > On Thursday, July 7, 2016 11:58:43 AM PDT Timothy Arceri wrote: > > > > This will be used to store the total number of components used > at this location > > > > when packing via ARB_enhanced_layouts. > > > > --- > > > > src/compiler/glsl/glsl_to_nir.cpp | 1 + > > > > src/compiler/glsl/ir.h | 5 +++ > > > > src/compiler/glsl/link_varyings.cpp | 74 > ++++++++++++++++++++++++++++++++++++- > > > > src/compiler/glsl/linker.cpp | 2 + > > > > src/compiler/glsl/linker.h | 4 ++ > > > > src/compiler/nir/nir.h | 5 +++ > > > > 6 files changed, 89 insertions(+), 2 deletions(-) > > > > > > I still hate this field. I'm going to try and come up with an > alternate > > > solution. I'll keep you posted.
I look forward to any suggestions :) > > > > On a first brush, me too. > I still haven't finished reading but here's a maybe useful (don't > count on it; I'm working on half a brain right now) suggestion: It > seems rather easy to declare an array uint8_t > components[MAX_LOCATION] and do a real quick walk of the inputs to > populate it. Then we can just use that when we set up interpolation. I believe the problem I was having was with arrays, see patch 4. On top of that as far I can tell the spec allows arrays starting at different locations and of different sizes etc to be packed together. I believe there is likely still corner cases my series doesn't catch yet to do with arrays but I haven't yet created piglit tests to cover ever scenario. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
