search

gfx-rs / gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
http://gfx-rs.github.io/
Apache License 2.0
5.35k stars 549 forks source link

Remove Framebuffers from the API #3552

Closed thorjelly closed 3 years ago

thorjelly commented 3 years ago

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.

kvark commented 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.

kvark commented 3 years ago

Highly related to, and can potentially be closed by, #3568 . I'm still trying to figure the way to go.

kvark commented 3 years ago

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