materials: introduce MaterialCache

[elizagamedev]

Presently, Filament Materials are instantiated by first parsing a bunch of read-only data from a material file, then applying a bunch of options from its Builder before settling on a final, immutable Material object. If two different Material instances need to be parameterized differently, e.g. setting their spec constants independently, each has to do all of these steps independently for each variation.

This change introduces two new concepts: MaterialDefinition, representing the deserialized, read-only state of a material file, and MaterialCache, a reference-counted system responsible for managing the lifetimes of MaterialDefinitions. Now, each Material asks the cache if a MaterialDefinition exists for the particular UUID of the data it's trying to read; if not, MaterialCache creates a new entry transparently. If a hundred different Materials all try to load the same material data, only one MaterialDefinition (and its associated GPU resources) will be created.

This first PR is the least possible invasive implementation of this feature. There are a lot of room for improvements (and more planned). For example, each Material still manages its own compiled shader program cache, but we can easily move this to the MaterialCache in future PRs, further enabling the planned mutable spec constants feature.

Additionally, there's room here to add a Material::toBuilder() method, which could take an extant material and create a Builder object from it already parameterized with all of the same options, a la the prototype design pattern.

[elizagamedev]

Oops, just realized I forgot to do the messy work of getting this working with matdbg. I'll comment again when I get that working.

[elizagamedev]

Okay, fixed matdbg.

[bejado]

Now, each Material asks the cache if a MaterialDefinition exists for the particular UUID of the data it's trying to read; if not, MaterialCache creates a new entry transparently. If a hundred different Materials all try to load the same material data, only one MaterialDefinition (and its associated GPU resources) will be created.

I've only just started reading through your implementation, so maybe I'm missing something obvious, but I think there's an issue here relying on a material's cache ID (parser->getCacheId()), which is perhaps poorly named. The cache ID only takes into account the vertex and fragment blocks and material version (see MaterialBuilder.cpp). So if, for example, specularAntiAliasing changes, the cache ID won't.

[elizagamedev]

I've only just started reading through your implementation, so maybe I'm missing something obvious, but I think there's an issue here relying on a material's cache ID (parser->getCacheId()), which is perhaps poorly named. The cache ID only takes into account the vertex and fragment blocks and material version (see MaterialBuilder.cpp). So if, for example, specularAntiAliasing changes, the cache ID won't.

Hmm, in that case, maybe the CRC32 is better. I could also change the key of the hashmap to also do a direct memory comparison in the case of a collision.

[elizagamedev]

Hmm, in that case, maybe the CRC32 is better. I could also change the key of the hashmap to also do a direct memory comparison in the case of a collision.

Done.

[pixelflinger]

only minor naming comments

[pixelflinger]

@elizagamedev iOS and web are failing FYI.

[pixelflinger]

I've only just started reading through your implementation, so maybe I'm missing something obvious, but I think there's an issue here relying on a material's cache ID (parser->getCacheId()), which is perhaps poorly named. The cache ID only takes into account the vertex and fragment blocks and material version (see MaterialBuilder.cpp). So if, for example, specularAntiAliasing changes, the cache ID won't.

Hmm, in that case, maybe the CRC32 is better. I could also change the key of the hashmap to also do a direct memory comparison in the case of a collision.

So yes, "cache id" is indeed poorly named. It specifically only caches was goes into "Program". So it's not good for caching packages, however, it's good for caching programs (in the future). e.g. two packages with different blending modes, could have the same shaders (internally Program also mixes in the variant and the spec constants).