[Impeller] Allocate buffers out of a pool on the raster thread.

[jonahwilliams]

flutter/flutter#129392

Buffer allocations on worker threads can interefere with allocations on the main thread. Since all buffers that we allocate on the main thread are discarded after a frame, we can use a ring buffer of VmaPool objects with a linear allocate bit to get faster allocations.

This works for buffers because they are likely to be suballocated, so we can continue to reuse the same memory over and over. Whereas most of our textures require dedicated allocations.

In order to support this, we need the allocator to track an incrementing frame counter (actually this would probably be useful for the context to do in general, but we'll get there eventually).

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[jonahwilliams]

This is an assumption that the thread which invokves IncrementFrame is the raster thread and will do most of the allocation. This is important to keep worker thread allocations in the default pool.

[jonahwilliams]

3 seems like a reasonable number since it matches the most common swapchain count. In theory with a higher swapchain count a buffer from a pool could still be in use by the time we come back around, but that wouldn't actually cause any issues beyond higher memory use.

[jonahwilliams]

Man I just cannot figure out why this CI machine doesn't have any of these memory types.

[jonahwilliams]

Making this optional for now as the host unittests don't seem to be able to create the same buffer pools that real devices do.

[chinmaygarde]

This depends on the caller explicitly telling Impeller that a frame was rendered. I'd like to keep caller responsibility w.r.t this to a minimum. in ContextVK, I keyed the surface acquisition as being a close enough proxy for frame generation. Thats how the pipeline library knows how many ticks have happened so it can decide when to persist the PSO cache. I suggest we do the same here. See ContextVK::AcquireNextSurface.

[jonahwilliams]

Ahh that is just what I'm looking for, thank you.

[chinmaygarde]

Pools, allocators, and allocations are getting pervasive enough that not having RAII wrappers is getting hard to reason about. In this patch or another if you prefer, can we wrap these in fml::UniqueObject please?

[jonahwilliams]

I think I could make one for the allocator, but the pools also need an allocator for disposal and it doesn't look like fml::UniqueObject supports a userdata like ptr I could use for that. Is that a reasonable update you could make to support disposing pools?

[chinmaygarde]

I know this is just modifying existing code, but can we use vk::MemoryPropertyFlagBits here (the C++ variant)?

[jonahwilliams]

how do I convert the vk::Flag type back to the C bits for VMA?

[chinmaygarde]

You can just static cast it to the underlying type. The header says enum class MemoryPropertyFlagBits : VkMemoryPropertyFlags. You can even use decltype for it. But your call as this isn't how the code works now.

[jonahwilliams]

ahh makes sense