* slice: fix memory semantics
* slice: prefer passing slice by value
This lets us do nice things like coercing Slice<T> to Slice<const T>, etc.
* slice: fix unit tests
* slice: fix copy/assignment, hash function
Don't attempt to define a copy constructor/assignment operator which would
convert a constant type to a mutable type.
Additionally, fix the hash function such that we're hashing U instead of const
U.
* fix a HwProgram leak related to depth variant pre-caching
Materials that don't use a custom depth can share the same program for
all depth variants. We take advantage of that by pre-caching the
depths variants when a program is loaded. The depth variants themselves
are owned by the default material which is created first. When a
material is destroyed it skips deletion of those variants which will
be truly destroyed when the default material is destroyed.
Unfortunately, the default material doesn't contain all depth variants,
in particular, it doesn't have the VSM ones (because it's an unlit
material). On top of that, the way it pre-cached depth variant had
a bug that made it miss some picking variants.
Because of that, these variants were skipped during material destruction
but never actually destroyed, since the default material didn't know
anything about them.
This PR fixes this by making the pre-caching completely lazy. When
any material needs such a "precacheable" variant, it first checks if
the default material has it. If not, it creates the variant, caches it
locally and forwards it to the default material, which implicitly
becomes the owner. Just like before newly created material precache
everything the default material already has.
With this mechanism, it's impossible to have a depth variant without it
also existing in the default material.
This also simplify the non-public invalidate() method, which doesn't
need to populate the pre-cached programs, since this will happen
naturally when needed.
There was also another issue where post-process materials were
handled like regular materials. This didn't cause an problem but was
inefficient since these only have a handful of variants.
* Update filament/src/details/Material.cpp
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
Material::compile() can be used to asynchronously ask the backend to
compile a subset of the variants of a Material and be notified when
done. This can be used during initialization to avoid hiccups later.
This will also force caching of those material programs if the
Platform provides the blob cache API.
This works by first generating a reflection buffer which gets blurred,
then the color pass samples from this buffer according to the roughness
of the surface being rendered.
A lot of the changes here involve utilizing "reserved" variants for
the new "SSR" pass and all the fallout from that.
Variants are no longer just a bit mask, but rather a combination of
some bits, depending on the variant. Because of that the variant filer
must be updated.
Basically we now make a distinction between the "variants" as a public
material API and the actual `Variant` data type.
This change does the impedance match between the two.
