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 547 forks source link

Exposing Vulkan 1.1 entry points. #3146

Open bzm3r opened 4 years ago

bzm3r commented 4 years ago

Problem

Currently, gfx-backend-vulkan only exposes Vulkan 1.0 to the user. See here and here in particular.

Vulkan 1.1 has exposed subgroup operations (see also this presentation), which are very nice for compute applications in particular, but will also likely become prevalent in graphics applications in the near future. A gfx-hal user cannot currently access these, due to the hardcoded Vulkan 1.0 usage set by gfx-backend-vulkan.

@msiglreith informed me that spirv-cross is already capable of handling SPIR-V 1.3 (Vulkan 1.1), so in order to use subgroup operations through gfx-hal, I think this is the only blocker?

Solution

I do not have enough API design knowledge to suggest how one can expose Vulkan 1.1 to the user. My best guess would be using feature flags, so that feature flag vulkan loads Vulkan 1.0, while feature flag vulkan1.1 loads Vulkan 1.1. Then we could have for instance:

#[cfg(feature="vulkan")]
use ash::version::{DeviceV1_0, EntryV1_0, InstanceV1_0};
#[cfg(feature="vulkan1.1")]
use ash::version::{DeviceV1_1, EntryV1_1, InstanceV1_1};

(and similarly a cfg flag to set vk_make_version!(1, 1, 0) if vulkan1.1 is enabled?)

Conclusion

I am worried that this might be much more complicated than I am imagining it to be, but I am happy to implement to any solutions that are decided upon through discussion here.

msiglreith commented 4 years ago

Afaik ash has unified all the version variants, which currently means for us to use EntryCustom, Instance and Device. There should be no need for compile time distinction.