MetalDriver: Assert in debug mode due to recent SamplerGroups changes

[MrKepzie]

Describe the bug

The following assert triggers after rebasing to latest changes to SamplerGroups.

https://github.com/google/filament/blob/main/filament/backend/src/metal/MetalDriver.mm#L876

After tracking it down, it happens with the texture mKernelTexture created by IBLPrefilterContext::SpecularFilter and involves the sampler group created by the default MaterialInstance of mIntegrationMaterial.

To Reproduce Should be reproductible with anything that uses the IBLPrefilterContext

[bejado]

I'm having trouble reproducing with our samples that use IBLPrefilterContext. In particular, the usage in IBL.cpp does not seem to trigger it.

Does the assert fire 100% of the time for you? Is your app doing anything special?

[MrKepzie]

Our code snippet for the IBLPrefilterContext is:

      // The context has one instance living as long as the app
       auto iblPrefilterContext = renderDelegate->GetIBLPrefilterContext();
       {
           auto equirectangularToCubemapConverter = IBLPrefilterContext::EquirectangularToCubemap(*iblPrefilterContext);
           filament::Texture* environmentCubemap = equirectangularToCubemapConverter(_texture->GetTexture());
           {
               auto specularFilter = IBLPrefilterContext::SpecularFilter(*iblPrefilterContext);
               _reflectionsCubemap = specularFilter(environmentCubemap);
               engine->destroy(environmentCubemap);
           }
       }
       engine->execute();

Then we build our IndirectLight

 _indirectLight = filament::IndirectLight::Builder()
                    .rotation(filamentRotationMatrix)
                    .reflections(_reflectionsCubemap)
                    .intensity(_intensity)
                    .build(*engine);

Then after setting up the rest of the scene, we use renderStandaloneView and call engine->execute() to process all commands. This is in that calll to execute that the assert triggers (NB: at that point the IBLPrefilterContext code I pointed above has been executed long before.

N.B: We use Filament in single-threaded mode. I tried adding/moving around the execute() calls without luck. Will try to reproduce on a simpler case

[MrKepzie]

Just as a sidenote: we rebased and hit the same issue again. This time, we made the IBLPrefilterContext::SpecularFilter live as long as the IBLPrefilterContext until the engine is terminated,,and the problem is gone. The faulty texture is the kernel texture allocated in the SpecularFilter. For some reasons in our workload, if the SpecularFilter is destroyed too early (even after a flushAndWait()), the issue occurs.