Refactoring & adding SPARSE_BINDING to QueueType

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

Refactoring & adding SPARSE_BINDING to QueueType #3665

Closed Neo-Zhixing closed 3 years ago

Neo-Zhixing commented 3 years ago

We now have sparse binding thanks to #3521 but currently 'SPARSE_BINDING' is missing from 'QueueType'. This PR adds the 'SPARSE_BINDING' bit to QueueType by converting it from a enum to a bitflags struct.

Reference: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkQueueFlagBits.html

PR checklist:

[x] make succeeds (on *nix)
[ ] make reftests succeeds
[x] tested examples with the following backends: Metal, DX12, DX11, Vulkan

Neo-Zhixing commented 3 years ago

I agree that simply adding a supports_sparse_binding function could be easier. However this is a better match to the original Vulkan APIs. I'm not sure which one has a higher priority - API stability or matching Vulkan APIs?

Neo-Zhixing commented 3 years ago

I've opened another PR (#3667) that simply added supports_sparse_binding function to trait QueueFamily as suggested. Please merge that PR and close this one if preferred.

kvark commented 3 years ago

Thank you! This is very nice of you to provide the alternative. I'm not feeling strongly about this decision, but I merged #3667 as less of an intrusive solution. Philosophically, we wanted to follow Vulkan were possible, so that we can get Vulkan Portability nicely, and it's easy to find answers about the guarantees by reading the Vulkan spec. In practice, both of these needs dim compared to the need to have wgpu to run efficiently on gfx, so some parts of gfx get slightly adjusted to make this path fast and efficient (like the swapchain API). So it's fine to have the queue types stay.