Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically allocate render targets #348

Open
kvark opened this issue Jan 16, 2020 · 0 comments
Open

Dynamically allocate render targets #348

kvark opened this issue Jan 16, 2020 · 0 comments

Comments

@kvark
Copy link

kvark commented Jan 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant