210: Port to the new swapchain model r=kvark a=kvark Closes #208 Fixes #212 Also has general fixes to: - push constant offsets in `gfxCreatePipelineLayout` - destination subresources in `gfxCmdResolveImage` The PR is inviting for discussion: @grovesNL @msiglreith I'm not 100% sure what to do yet. The Good: 1. Being able to remove the old swapchain from gfx-rs COMPLETELY. It was hacky on all the backends other than Vulkan, quite complicated on Metal, and didn't work very in general. 2. Fullscreen support! It's not ideal yet (occasional hitches), but it was pretty much non-functional before. In general, stuff that runs is more robust this change. The Bad: 1. Portability implementation is a bit more complex now, but not extraordinary so. In general, I think it's a win if we move some complication out of gfx-rs into gfx-portability, since gfx-rs has more users, it's more important to keep clean. 2. We can't support recording a render pass that uses a swapchain image if either: - the image is not acquired at the moment of recording - the command buffer is re-usable. We expect the users to strictly acquire-record-submit-present. The Ugly: 1. Our KHR swapchain implementation is more limited: no support for any usage other than COLOR_ATTACHMENT. This is technically valid in Vulkan, but for some reason many apps expect to transfer to/from swapchain images. So this is fine for the matter of CTS and VkPI, but can introduce some friction in real world testing. 2. The new swapchain model itself needs to be evolved a bit more, according to gfx-rs/gfx#3184 . We don't know how exactly: there is both a risk (that we'll need to redo something here) and an opportunity (that we'll support other usages, for example). Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>

Support the new gfx-hal swapchain model #208

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions