Timothy Arceri <tarc...@itsqueeze.com> writes: > I think I'd rather see this handled by releasing the uniforms only after > the second link is successful and using a temp/fallback pointer to hold > it until then. We need to do a similar type of thing with shader source > and the shader cache e.g [1]. > > [1] > https://cgit.freedesktop.org/mesa/mesa/commit/?id=e5bb4a0b0f4743fa0a0567991dca751ef49a7200
You’re right, I think that would be a better way to handle it. I guess if this was done then you don’t really need the second link. There are several pointers for the uniform state that you would need to keep and I think there is more state than just the uniforms as well. Perhaps pretty much everything that is freed in _mesa_clear_shader_program_data should be kept? An ideal solution might be to refactor this state into two seperate structs. One would contain everything the user can edit, such as the list of shaders to link, AttributeBindings, SSO flag etc, and the other would be everything that is the result of linking. That way the link could fill in a newly allocated link-state struct and only replace the old state after a sucessful link. My (perhaps lazy) hunch is that that could be a rather intrusive refactor and if the only reason to do it is to fix this obscure corner case then it might not be worth the hassle. I might try to have a go at this anyway but it’s probably the sort of thing that would need some discussion first. Regards, - Neil
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
