[Mesa-dev] [PATCH] mesa/shaderapi: Do a dry run of linking an in-use program

[Timothy Arceri]

On 07/11/17 19:15, Neil Roberts wrote:
> Timothy Arceri <tarceri at 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
>