buffer update opt: Integrate UboManager into the engine

[show50726]

To focus on the integration logic added in this PR, please ignore BufferAllocator and UboManager and their related tests. They were introduced in the base PR (#9331).

Changes

• Engine
  • The engine now owns the UboManager. It initializes it, calls its beginFrame/endFrame methods, and manages MaterialInstance slot retirement on destruction.
• MaterialInstance
  • Constructors are updated to accept a useUboBatching flag.
  • commit() now writes data to the shared buffer via uboManager->updateSlot.
  • use() now binds the shared buffer using its dynamic offset.
• Material
  • createInstance() methods are updated to pass the useUboBatching flag to the MaterialInstance.
• PostProcessManager
  • All calls to mi->commit(driver) are updated to mi->commit(driver, mEngine.getUboManager()) to pass the manager.
• Renderer
  • At endFrame(), it now notifies the UboManager to create a fence for GPU synchronization.
• filamat
  • Updated to set the DYNAMIC_OFFSET flag for the material's uniform buffer, so that it could update the offset without recreating the descriptor set.

[pixelflinger]

no need to return the optional and check isUboBatchingEnabled(). I would keep the isUboBatchingEnabled() check and just write engine.getUboManager()->endFrame()

[show50726]

Done.

[poweifeng]

why is it necessary to add the bool here?

[show50726]

I guess sometimes there is case that we need to create a new MI from a defaultMaterial instance.

Since defaultMaterial instance needs to be committed right after it is created, I exclude it from using UBO batching, but for the MI that is created from the defaultMaterial I think they should have the ability to be using UBO batching.

I'm not sure if this case would really happen though, any thought?

[poweifeng]

IMO this is uncommon - to have many instances of the default material. I think it's ok to not offer that option for duplicate() and the duplicate constructor of FMaterialInstance.

But defer to @pixelflinger

Sidenote:
I think to add this, you'd also have to expose the option in the public MaterialInstance::duplicate()?

[show50726]

Let me think more about this and get back to you.

[pixelflinger]

I just realized, did you handle FRenderer::renderStandaloneView? I don't think you did.

[show50726]

I just realized, did you handle FRenderer::renderStandaloneView? I don't think you did.

I did (in the latest commit).
In renderStandaloneView, there is engine.prepare(), it already called UboManager::beginFrame() and UboManager::finishBeginFrame(). Now I added UboManager::endFrame() to renderStandaloneView(), so the gpuUseCount will be updated correctly. Everything is working same as the normal render() path.
(Note that the gpuUseCount of the slots will be decreased at the beginning of the next render call)

I also tested with a custom app which calls renderStandaloneView twice and verified it works correctly.

Note: I feel like it makes more sense to add an endFrame to FEngine to wrap the UboManager::endFrame logic so that we could just call engine.endFrame() in both render and renderStandaloneView paths. Updated.