On 08/11/17 02:35, Neil Roberts wrote:
Timothy Arceri <tarc...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
