On 07/11/17 19:15, Neil Roberts wrote:
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?
You only need to keep things that are accessed by the backend post
linking (such as the uniforms), things that are queried via the api can
be trashed as per the spec. I'm pretty sure we don't need most of those.
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
