Alternative API backend

[kvark]

gfx-rs has a low-level layer that is being worked on. It's not exactly Vulkan, but could technically be wrapped into Vulkan API in order to provide a more portable solution (that runs on Metal/DX12) than the native Vulkan (see gfx-rs/gfx#1226).

It would be interesting to explore an option to use gfx-rs coreLL with Vulkano as a front-end. I suspect this would require some changes in Vulkano to make sure the backend is swappable.

[tomaka]

Vulkano will probably only ever support the Vulkan API directly, but if gfx implements a Vulkan-compatible FFI (as suggested in gfx-rs/gfx#1226) then vulkano supporting it is just a matter of implementing #361.

[kvark]

@tomaka I believe it to be very important to call our portability functions statically as opposed to via function pointers (like a regular Vulkan loader exposes). We try very hard to make the most frequently used functions to have a little logic as possible, e.g. drawXXX in Metal/DX does nothing but calls the underlying draw function, so having them inlined could make a difference.

My original (old?) plan was to glue things together using a Vulkan binding generator. I haven't yet verified if this is the right way to go. Can you share your thoughts on how to get right and whether or not you consider this effort worth pursuing (statically dispatched portability calls)? Also, do any of the choices listed in gfx-rs/gfx#2206 (comment) really affect anything on your side, if we are to use Vulkano together with the portability layer?

[tomaka]

My original (old?) plan was to glue things together using a Vulkan binding generator.

It's kind of hard to be generic over both dynamic loading and static loading, but I agree that ideally vulkano should support the latter as well.

I don't really have a plan in mind for this though.

Right now vulkano allows you to choose how to load the function pointers, but maybe we may wish to remove this? I'm not sure.