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

[Timothy Arceri]

On 08/11/17 02:35, Neil Roberts wrote:
> 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.

Ok I've taken a closer look at all this, I was sure I did a bunch of 
work to avoid this issue and it seems I didn't finish off the last 
couple of steps (I think part of the issue was not having a piglit test 
for it at the time, thanks for fixing that). I'll send a patchset shortly.

> 
> https://github.com/bpeel/piglit/commit/d95701afbb9367ed1e82af27c98f18
> 
> Regards,
> - Neil
>