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

[Neil Roberts]

Timothy Arceri <tarceri at itsqueeze.com> writes:

>> 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.

Right, I guess we could keep a small selection of the pointers that are
cleared by _mesa_clear_shader_program_data. However it might be messy to
maintain as it’s likely that someone could add new members to
gl_shader_program_data and forget to update this function. Already just
preserving the neccessary uniform state is a bit fiddly because the
allocation we want to maintain is owned by UniformStorage but it is
accessed via UniformDataSlots in the i965 driver. I’m not exactly sure
how this works in Gallium.

Just to double check, I made a little Piglit test to check using atomic
counters and sure enough it gets a similar Valgrind error and sporadic
failures due to accessing shProg->data->AtomicBuffers, so we would at
least need to conserve that too.

https://github.com/bpeel/piglit/commit/d95701afbb9367ed1e82af27c98f18

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/f912abdb/attachment.sig>