[Mesa-dev] [PATCH 3/4] glsl: add ir_cache class and functions for shader serialization

Tapani tapani.palli at intel.com
Fri Nov 1 23:30:05 PDT 2013

On 11/01/2013 06:41 PM, Eric Anholt wrote:
> Tapani Pälli <tapani.palli at intel.com> writes:
>> On 10/29/2013 03:48 PM, Paul Berry wrote:
>>> On 29 October 2013 00:53, Tapani <tapani.palli at intel.com
>>> <mailto:tapani.palli at intel.com>> wrote:
>>>>          +}
>>>>          +
>>>>          +
>>>>          +/* data required to serialize ir_variable */
>>>>          +struct ir_cache_variable_data
>>>>      As with glsl_type_data, I don't understand why we need to have
>>>>      this class rather than just adding a serialize() method to the
>>>>      ir_variable class.
>>>      This could be a serialize function in ir_cache_serialize.cpp. I
>>>      did not want to touch existing ir classes, I think it helps to
>>>      have the cache code separated and in one place. This is of course
>>>      debatable, every ir instruction could have serialize() and
>>>      unserialize() to deal with this.
>>> My chief worry with separating them is that people will forget to
>>> update the serialization code when they change the ir class, because
>>> the thing they need to update will be far away.  This is particularly
>>> a problem when adding new members to the class (something we do quite
>>> frequently when implementing new GLSL features).
>> I understand and I've been worried about this from the maintainability
>> point of view as well. I've thought to add some documentation on the
>> ir.h file about this.
> If it's not tested, it will break, and documentation will only help you
> say "I told you so!", which is not very useful.  This is why we've been
> emphasizing automatic caching over get_program_binary -- because
> everyone (except crazy RO root systems) will always be using it,
> developers will actually catch the bugs.

Ok *sigh* I'll revisit the architecture and try to get automatic cache 
to work first.

// Tapani

More information about the mesa-dev mailing list