In the new swapchain model, which became the one and only model as of #3327, users are not able to pre-create framebuffers for every swapchain image in advance. We settled on the requirement for the user to create a framebuffer for every frame they render, and then remove it after presenting. This didn't fit into the low-level API too well, and Vulkan backend had to implement the smarts of tracking the use of swapchain-related framebuffers. See more detail by @thorjelly in #3552.
Status
This PR removes framebuffer as a concept, leaving it to be an implementation detail of the backends.
Currently it's done for HAL, Vulkan, and Metal.
Biggest concerns:
OpenGL backend complexity/consistency
Analysis
Effect on the API: great, simpler API. Especially the new RenderAttachmentInfo struct. We already had a slight divergence with Vulkan on the clear values in begin_render_pass, and this PR makes it look very solid and concise.
Effect on the user: great, less things to manage, especially the fact that we don't have "special" framebuffers versus the regular ones any more.
Effect on performance:
Vulkan: minimal.
It's now easier to internally reuse those framebuffers.
We have anecdotal evidence that of all the Vulkan implementors only one mobile vendor can actually do anything useful with the framebuffer object, and others don't use it.
OpenGL: negative, we can no longer create FBOs in advance
other: no effect
Effect on the code complexity:
Vulkan: positive, there is no special-casing any more, no managing of the "owner" of framebuffers.
Metal: positive, also less special-casing.
OpenGL: negative. Unlike Vulkan, we can't just create an FBO on the spot while recording, since it's done off-line. So we'll have to have internal commands elevated to higher level, i.e. SetRenderTargets instead of BindFramebuffer.
Finally, this helps streamlining the path from wgpu to the hardware, as WebGPU doesn't have framebuffers either.
kvark
commented
3 years ago
Closes #3552
History and motivation
In the new swapchain model, which became the one and only model as of #3327, users are not able to pre-create framebuffers for every swapchain image in advance. We settled on the requirement for the user to create a framebuffer for every frame they render, and then remove it after presenting. This didn't fit into the low-level API too well, and Vulkan backend had to implement the smarts of tracking the use of swapchain-related framebuffers. See more detail by @thorjelly in #3552.
Status
This PR removes framebuffer as a concept, leaving it to be an implementation detail of the backends. Currently it's done for HAL, Vulkan, and Metal. Biggest concerns:
Analysis
Effect on the API: great, simpler API. Especially the new
RenderAttachmentInfostruct. We already had a slight divergence with Vulkan on the clear values inbegin_render_pass, and this PR makes it look very solid and concise.Effect on the user: great, less things to manage, especially the fact that we don't have "special" framebuffers versus the regular ones any more.
Effect on performance:
Effect on the code complexity:
SetRenderTargetsinstead ofBindFramebuffer.Finally, this helps streamlining the path from wgpu to the hardware, as WebGPU doesn't have framebuffers either.