Closed thorjelly closed 3 years ago
After spending a lot of effort on #3560, it makes me sad to see this abstraction go. I'm now trying to refactor the swapchain API in a different way, while keeping the framebuffers around.
Highly related to, and can potentially be closed by, #3568 . I'm still trying to figure the way to go.
I realized one important API piece that becomes really sad if we remove the framebuffers entirely - it's the command buffer inheritance info. This is where having image-less framebuffer is ideal. Without it, we'd have to pass something similar, if not the full attachment list, into the inheritance info... which would be very sad from the API perspective.
With this in mind, I'm closing the issue in favor of #3568
This was a topic that was brought up in the matrix chat. I was asked to create an issue.
Essentially, now that the swapchain was removed from the API, the control over swap images (and thus framebuffers which contain swap images) was taken away from the user. We must reacquire a swap image every frame, and we must recreate a framebuffer that uses it every frame. To compensate, framebuffers are cached internally by the vulkan backend, but only if they contain a swap image.
It feels unintuitive and inconsistent that this caching behavior exists for swapimage framebuffers and only for swapimage framebuffers. It'd be nice if it extended to all framebuffers. But then, what is the point of exposing framebuffers in the first place? I imagine the reason why framebuffers are exposed in Vulkan is to take that responsibility away from the device/driver and give it to the user, but currently the user of gfx-rs does not have full control over framebuffers (because of the caching behavior and the removal of the swapchain). Perhaps the next logical step is just to remove framebuffers from the API entirely and extend the internal caching behavior to support all framebuffers.