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

Neil Roberts nroberts at igalia.com
Tue Nov 7 08:15:05 UTC 2017


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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171107/fd5c29f9/attachment.sig>


More information about the mesa-dev mailing list