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

Alternative API backend #525

Closed
kvark opened this issue Jun 16, 2017 · 4 comments
Closed

Alternative API backend #525

kvark opened this issue Jun 16, 2017 · 4 comments

Comments

@kvark
Copy link

kvark commented Jun 16, 2017

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

tomaka commented Jul 12, 2017

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

kvark commented Jul 6, 2018

@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
Copy link
Member

tomaka commented Jul 8, 2018

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.

@Rua
Copy link
Contributor

Rua commented Aug 8, 2022

This probably will never happen, but Vulkano has since moved to using Ash as a backend.

@Rua Rua closed this as completed Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants