On Thu, 2016-10-27 at 18:51 -0700, Kenneth Graunke wrote: > On Thursday, October 27, 2016 9:03:12 PM PDT Timothy Arceri wrote: > > > > On Thu, 2016-10-27 at 12:37 +1100, Timothy Arceri wrote: > > > > > > Agreed but as far as I can tell we shouldn't even need > > > gl_linked_shader > > > after glLinkProgram. > > > > > > We should probably just free it after linking. Everything we want > > > *should* have been copied to gl_program, however in practice it > > > seems > > > there are some things we still get from gl_linked_shader > > > like NumImages, but with the changes I landed recently we could > > > just > > > be getting this from the new shader_info struct. > > > > I've started work on this: > > > > https://patchwork.freedesktop.org/series/14471/ > > > > But I'm not sure I have is in me to do another big refactor right > > now. > > Is there a reasonable short-term fix? This regression is present on > the 13.0 branch and we really ought to fix it before Emil cuts the > 13.0 > final release. But it'd be nice if we could keep some freeing of > IR...
I was thinking about this yesterday and the only options I see are using this patch for the 13.0 branch or leaving it broken. The scenario for this bug is highly unlikey you need to be in compat profile, and relinking a SSO program that has had its shaders detached. > > Refactoring is probably a good idea in the longer term.... Looking at things yesterday I think there are some bugs (at least in i965) we would hit currently with atomics and images if we were to fail relinking a program, and then the program was to recompile a shader variant due to storing state in gl_linked_shader. > > --Ken > _______________________________________________ > 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
