Support Vulkan Surface without TRANSFER_DST capability

[kvark]

Is your feature request related to a problem? Please describe.
I'd like to be able to run Filament on a VK_KHR_Surface implementation that doesn't expose TRANSFER_DST usage.

Describe the solution you'd like
If copying to a swapchain image is not required, make it truly optional. Blitting could be replaced by sampling from an image and rendering into the swapchain - if this is done within the same render pass, it will likely be faster on mobile GPUs than a follow-up blit anyway.

Describe alternatives you've considered
Require TRANSFER_DST.

OS and backend
This is macOS over Vulkan Portbility.

[romainguy]

Could you explain the use case for this request please?

[kvark]

A theoretical use case is running on any Vulkan implementation that doesn't support TRANSFER_DST. It's a perfectly valid thing to not support.

More specifically, we are evaluating a new swapchain model in gfx-portability (gfx-rs/portability#210), which doesn't support this usage. We would like to run Filament without local modifications :)

[romainguy]

I get that, but what is an implementation that doesn't support TRANSFER_DST? I'm mostly curious :)

[kvark]

We are evaluating a switch in gfx-portability architecture (which is a Vulkan Portability implementation on top of Metal, D3D12, and more) that would only support COLOR_ATTACHMENT usage for the swapchains.

[prideout]

Thanks for filing this @kvark (btw I'm a fan of your work on wgpu) but it went past my radar. We could conceivably support a VK implementation that doesn't support TRANSFER_DST but it would be non-trivial.

Is the gfx-portability initiative still going full steam ahead? If not maybe we can close this.

[kvark]

No, it's currently on hold. And even if/when it's resumed, we'll be find with TRANSFER_DST. Closing.