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. https://github.com/bpeel/piglit/commit/d95701afbb9367ed1e82af27c98f18 Regards, - Neil
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
