On Sat, 3 Oct 2015 11:59:49 +0200 gregory hainaut <gregory.hain...@gmail.com> wrote:
> On Sat, 03 Oct 2015 09:35:49 +0000 > Mike Lothian <m...@fireburn.co.uk> wrote: > > > Would it be better to have is_interstage=0 rather than a double negative? > > > Yes. I think it just need to set 1 in the constructor (forget to > update it by the way...) as default value. Otherwise it can be > renamed to is_unlinked_io (or something similar). > > > > > > > In short, SSO allow to match by name but you can't make any hypothesis > > > on the > > > > previous/next stage. Therefore you must consider all inputs and output > > > > as > > > > actives. > > > > > > New version based on Ian's feedbacks. > > > * Real interstage variables of the program are still optimized > > > * Both output and input of the program remains active > > > * An old bug still remains if name and explicit location rendezvous are > > > mixed > > > > > > Commits decription: > > > 1/ add a not_interstage parameter that will be 1 when variable is either > > > an > > > input of output of the program. I didn't know where to put the > > > ir_set_not_interstage_io > > > function. Maybe it can be moved in linker.cpp. > > > 2/ Set the interstage parameter based on the shader position in the > > > pipeline > > > program. Potentially can be squased with the previous one. > > > 3/ Don't do deadcode removal of not_interstage variable with the exception > > > of the built-in varyings because they don't impact location of others > > > variables > > > > > > Gregory Hainaut (4): > > > glsl IR: add not_interstage attribute to ir_variable > > > glsl link: annotate not_interstage attribute of the ir_var after link > > > phase > > > glsl IR: only allow optimization of interstage variable > > > allow compilation on my system > > > > > > configure.ac | 6 ++++-- > > > src/glsl/ir.h | 6 ++++++ > > > src/glsl/ir_optimization.h | 2 ++ > > > src/glsl/linker.cpp | 47 > > > ++++++++++++++++++++++++++++++++++++++++++++++ > > > src/glsl/opt_dead_code.cpp | 37 ++++++++++++++++++++++++++++++++++++ > > > 5 files changed, 96 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.1.4 > > > > > > _______________________________________________ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > I found another issue with my application (lucky me). out SHADER { vec4 t; vec4 c; flat vec4 fc; } VSout; in SHADER { vec4 t; vec4 c; flat vec4 fc; } PSin; will be transformed into the following interface in SSO (in varying_matches::record) to out SHADER { flat vec4 t; flat vec4 c; flat vec4 fc; } VSout; in SHADER { vec4 t; vec4 c; flat vec4 fc; } PSin; It doesn't change the interpolation/rendering as it will use the one from the FS. However it will affect the match_comparator function. So the sorting in varying_matches::assign_locations will behave differently for some parameters. I don't know how to handle this. Either we could adapt the sort function to mask the flat value. Or we mustn't add the flat qualifier. Any opinions or other solutions? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
