Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Vulkan Surface without TRANSFER_DST capability #2342

Closed
kvark opened this issue Apr 6, 2020 · 6 comments
Closed

Support Vulkan Surface without TRANSFER_DST capability #2342

kvark opened this issue Apr 6, 2020 · 6 comments
Assignees
Labels
enhancement New feature or request vulkan Issues with the Vulkan backend

Comments

@kvark
Copy link

kvark commented Apr 6, 2020

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
Copy link
Collaborator

Could you explain the use case for this request please?

@romainguy romainguy added enhancement New feature or request vulkan Issues with the Vulkan backend labels Apr 6, 2020
@kvark
Copy link
Author

kvark commented Apr 6, 2020

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
Copy link
Collaborator

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

@kvark
Copy link
Author

kvark commented Apr 6, 2020

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
Copy link
Contributor

prideout commented Mar 3, 2022

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
Copy link
Author

kvark commented Mar 4, 2022

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

@kvark kvark closed this as completed Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request vulkan Issues with the Vulkan backend
Projects
None yet
Development

No branches or pull requests

4 participants