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

Reply via email to