We are currently spending insane amount of time in creation and destruction of render targets per frame (~ 1/3 of the whole CPU time on the Renderer). WebRender upstream tries really hard to re-use previously created targets, in order to avoid the allocation. Fortunately, in Vulkan world we separate the allocation from render target creation, therefore we should be able to re-create the necessary targets every frame.
Here is roughly what we can do. Have a relatively large memory chunk for most (if not all) render targets needed this frame. We'll need to be able to manage multiple such chunks, but for the purpose of explanation here let's assume everything fits into one.
The general approach of WebRender is ping-pong: once a render pass is done, it serves as input to the next pass, after which the target can be safely re-used.
The new implementation could start a frame with the full memory chunk available to targets.
For each render pass (in WR terms, so it may contain multiple color and alpha layers), we'd sub-allocate memory and declare the new images (and render targets - image views) on it.
After we finish the pass, we still keep the memory around as well as the images.
The pass contents are used as inputs by the following pass (which also allocates its own targets on our chunk of memory).
After the following pass, we return back the sub-range of memory, so that we can re-use it for the other passes this frame.
At the same time, we don't delete the images and image views. We keep them associated with the current frame and only actually delete when the corresponding fence is done.
This means, at any given time there can be many different images pointing to the same memory
This can be better than the current GL implementation because we don't need to try hard to re-use the existing targets. Moreover, we can re-use memory if, say, a format has changed, or the size is slightly different.
We are currently spending insane amount of time in creation and destruction of render targets per frame (~ 1/3 of the whole CPU time on the Renderer). WebRender upstream tries really hard to re-use previously created targets, in order to avoid the allocation. Fortunately, in Vulkan world we separate the allocation from render target creation, therefore we should be able to re-create the necessary targets every frame.
Here is roughly what we can do. Have a relatively large memory chunk for most (if not all) render targets needed this frame. We'll need to be able to manage multiple such chunks, but for the purpose of explanation here let's assume everything fits into one.
The general approach of WebRender is ping-pong: once a render pass is done, it serves as input to the next pass, after which the target can be safely re-used. The new implementation could start a frame with the full memory chunk available to targets.
This can be better than the current GL implementation because we don't need to try hard to re-use the existing targets. Moreover, we can re-use memory if, say, a format has changed, or the size is slightly different.