-
Notifications
You must be signed in to change notification settings - Fork 441
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
Alternative API backend #525
Comments
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. |
@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? |
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. |
This probably will never happen, but Vulkano has since moved to using Ash as a backend. |
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.
The text was updated successfully, but these errors were encountered: