Static linking support?

[repi]

Does gfx-portability support full static linking into an executable? I.e. not build and separately distribute it as a vulkan dll?

We (Embark) are quite interested of replacing the big MoltenVK C++ library (that we use through our ash-molten crate) with gfx-portability but we do need to be able to continue statically link in everything to a single executable

[kvark]

Hi! Yes, we have 2 FFI-compatible compilation targets:

• libportability - just exposes the Vulkan functions statically, can be linked directly into your application
• libportability-icd - exposes Vulkan ICD interface only

Both use libportability-gfx internally, which is the Rust API library implementing Vulkan on top of gfx-hal.

Things to keep in mind when considering gfx-portability:

• we support less extensions than MVK (e.g. no tessellation). We are very receptive to the needs of the client applications, so it would be great to know what your engine needs, and we can prioritize getting support for those.
• our swapchain model on Metal works entirely differently from MVK. The new approach in Port to the new swapchain model #210 is what we want all the clients to use in the end (same API, just more restrictive, but robust). If you can report that it works for you, this will be enough of a forcing function to get it landed (currently hanging because Dota2 doesn't work with it, and we can't fix that).
• we expect to be faster than MVK in most scenarios. We've done some extensive benchmarking on Dota2 and Dolphin emulator before, and we believe we have a better architecture. If gfx-portability is not faster, we'll consider that a bug.

[repi]

Ah cool, then it sounds like it should be possible to connect the Vulkan functions directly to the functions pointers the ash uses in a utility/integrate similar to what we did with ash-molten. cc @MaikKlein

Right now our needs are pretty basic (and no tessellation) so likely will work well out of the box, but if/when we do try it out we'll make sure to report any issues. Glad to hear about your "performance guarantee" :)

Compiling MoltenVK on my 6 core MBP15 took over 10 min from scratch, while building gfx-portability from scratch took 1 min, really nice.

Btw another question, what do you use for SPIRV -> MetalSL?

[kvark]

it should be possible to connect the Vulkan functions directly to the functions pointers the ash uses in a utility/integrate similar to what we did with ash-molten

Yes, it should be possible.
Earlier, we thought Ash bindgen can be extended to link to libportability-gfx directly without going through the FFI barrier (see ash-rs/ash#119), but I suppose using libportability as static lib is a simpler thing to get working.

while building gfx-portability from scratch took 1 min

That sounds quite fast indeed. I'm slightly confused as to why MVK would be building that much longer. I mean, Rust is known for its build times, and we have at least one extra logical layer of going through the gfx-rs traits (staticly dispatched, no perf concerns) between the Vulkan API and gfx-backend-metal. Oh, did you enable the "metal" feature when building? That would explain the difference :)

Btw another question, what do you use for SPIRV -> MetalSL?

We've been using SPIRV-Cross, relying on the work by MVK author and ARM so far.
In the meantime, we are slowly rolling out our own shader translation infrastructure in Naga. It's not nearly ready for production yet, but we have big plans for it (converting from WGSL/GLSL, converting to binary targets like AIR directly, and more). We've been having a whole lot of a trouble with SPIRV-Cross and are eager to replace it with a better solution.

[MaikKlein]

@kvark Thanks for the reply.

IIRC the last time I had a look at the portability lib I wanted to use portabilitiy-gfx directly, so that I can essentially just create a VkInstance.

https://github.com/gfx-rs/portability/blob/master/libportability-gfx/src/impls.rs#L59

I think the problem last time was that protability-gfx was using gfx-hal straight from master and I was running into build issues.

https://github.com/gfx-rs/portability/blob/master/libportability-gfx/Cargo.toml#L36

Felt a bit wrong to go through the c barrier when I am already in Rust. Also I think I'd actually need to modify the cargo.toml to give me a static lib right?

Any plans of using gfx-hal from crates.io instead of git for portabilitiy-gfx?

[kvark]

@MaikKlein hi!

I was running into build issues.

Not sure what build issues you are referring to: we have extensive CI coverage both here and on gfx-rs, all master branches should build without issues.

Also I think I'd actually need to modify the cargo.toml to give me a static lib right?

You mean libportability/Cargo.toml? I just did that in #215 :)

Any plans of using gfx-hal from crates.io instead of git for portabilitiy-gfx?

We haven't yet considered that. I suppose we'll have to do this in order for you to be able to publish anything like ash-portability.

In some projects, we keep the master to depend on the major dependency's master. For example, wgpu-rs depends on wgpu master. When it's time to release, we publish wgpu and make a branch in its repository for the release. At the same time, we make a branch in wgpu-rs for the release, where the dependency is switched to crates-io, then we publish from this branch.

I think the same scheme would make sense here. If you need to publish soon-ish, we can make a release of libportability-gfx that depends on gfx-hal-0.5. If not, we can start doing the releases once gfx-hal-0.6 is out.

[MaikKlein]

Not sure what build issues you are referring to: we have extensive CI coverage both here and on gfx-rs, all master branches should build without issues.

Because in the repo you have a Cargo.lock file that points to the correct git hashes, but I was using it as a library like portability-gfx = {git = "https://github.com/gfx-rs/portability"}

You mean libportability/Cargo.toml? I just did that in #215 :)

Oh nice, I didn't even know you could do that.

I think the same scheme would make sense here. If you need to publish soon-ish, we can make a release of libportability-gfx that depends on gfx-hal-0.5. If not, we can start doing the releases once gfx-hal-0.6 is out.

It is not something super urgent. Worst case scenario with #215 I can just treat this lib like moltenvk and compile/link it manually in a build.rs.

But it would be nice to have a proper crates.io release.

It would be nice to leave moltenvk behind :).