On 11/01/2013 06:41 PM, Eric Anholt wrote:
Tapani Pälli <tapani.pa...@intel.com> writes:
On 10/29/2013 03:48 PM, Paul Berry wrote:
On 29 October 2013 00:53, Tapani <tapani.pa...@intel.com
<mailto:tapani.pa...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
