Open jonahwilliams opened 5 months ago
If we do this naively, then we'll end up doubling the number of cmd buffers we submit. if we go back to a batching like API, it would be at most one extra cmd buffer.
One thing I'm stuck on though, is what sort of key to use for resource tracking. naively, we could just use the resource ptr as an int, but then we still need a way to clear those out when the resource is destructed. We absolutely must not make the resource state tracking keep the resource alive.
Currently layout state for Vulkan resources (mostly just images) is pretty hardwired, this leads to some edge cases where we need a hole punch to make things fast: https://github.com/flutter/engine/pull/52908
Could we do better here? Yes, but it would be some work. The approximate solution for us is likely to follow the outline in https://www.youtube.com/watch?v=d15RXWp1Rqo .
TLDR:
Track resource states per command buffer and per queue. Automatically insert barriers during queue submission if resource state doesn't match expected state of cmd buffer. Assume first usage in a cmd buffer is the correct state.
Unlike previous attempts, we do not track layout state globally per resource. We may need to output additional cmd buffers when submitting in order to transition resources to the correct state. This would be wasteful for common cases such as render passes, so maybe we explore a system where we always delay submitting the previously submitted cmd buffer so we can use it to hold layout transitions for the next cmd buffer.
This would also be a requirement to make flutter GPU feasible on Vulkan.