Consider partnering with gfx-portability instead of MoltenVK

[kvark]

Given the uplifting description of why you choose Rust linked from the Readme, I find it surprising that on macOS you rely on MoltenVK for graphics. There is a Rust alternative - gfx-portability that you can build with Cargo and link to, either as a static library, or as a dynamic, including using with Vulkan SDK/loader.

Also related to #373 and #233.
Obviously, this issue will become irrelevant if Rendy or wgpu-rs is going to replace Vulkano, which is pending investigation in #374.

[mitchmindtree]

Thanks @kvark, we are absolutely interested in partnering with gfx-portability - thanks a lot for reaching out! Let me share our graphics history with you so far:

I find it surprising that on macOS you rely on MoltenVK for graphics

Keep in mind it's been roughly 1.5 / 2 years since we decided to go with vulkano now. At the time it seemed the safer choice as gfx was undergoing major re-writes, and I believe the birth of gfx-hal, gfx-portability etc was only just kicking off at this point. vulkano on the other hand had a maintainer at the time and a much higher-level interface that comparatively seemed ready to go. As a result, we also invested time into getting moltenvk to work, as that was the only feasible approach forward we were aware of that was compatible with vulkano and the vulkano repo already had some discussion on getting it going. The vulkano guide, as short as it is, was also greatly influential in our decision to go with vulkano as the steps of integration were for the most part laid out before us.

Since then, the rust graphics landscape has changed considerably. By the end of our integration of vulkano, tomaka had faded out of maintaining vulkano entirely and soon after rukai also stopped due to time constraints. We now have maintainer-ship access to the vulkano crates, but we almost exclusively use it for trying to patch bugs that we run into. Meanwhile, gfx-rs has been making incredibly impressive strides toward an ambitious goal and the community around it has only been growing!

When we began using vulkano we were aware we would likely be contributing some patches, but a big part of choosing it was our lack of time to maintain and develop the lower-level graphics stack features - something that was continuing at a strong pace at the time but is no longer the case. So here we are now looking for alternative approaches, hence #374.

I think the key things blocking us from moving forward on a switch to the gfx ecosystem are:

• We are yet to determine whether rendy or wgpu is the right approach forward for nannou - I'll leave this discussion for Considering rendy and wgpu for use as nannou's graphics backend #374!
• We aren't really sure where to start with integration of either of those crates yet. We are still yet to take a closer look at the examples and API docs closely, but a guide or something similar would go a long way towards showing us the steps we need to take and if there are any holes yet to fill or that we should be asking about.
• We have had a lot of other nannou work we had been meaning to address since finishing the switch to vulkano, which was a significant change and a big learning experience for us coming from glutin and took a lot of time! We are reaching the point again where there are many graphics API features we would like to add but we have been avoiding doing so as we are aware of a need for a graphics backend re-write in the near future. So I think now is a good time to be discussing this!

[kvark]

Thank you for taking time to respond in such detail! I appreciate the history dive into your graphics journey, and it all makes sense.

Keep in mind it's been roughly 1.5 / 2 years since we decided to go with vulkano now. At the time it seemed the safer choice as gfx was undergoing major re-writes, and I believe the birth of gfx-hal, gfx-portability etc was only just kicking off at this point.

Truth is, gfx-portability was born (and operational to some extent) roughly 2 years ago, even before MoltenVK got open-sourced, which you can see on our contributor timelines: gfx-portability vs MoltenVK. Changes in gfx-rs API didn't affect gfx-portability, since the C API is set in stone. There were quality issues, missing features, etc, of course, but same largely applied to MoltenVK, just to a lesser extent. Both libraries now became more mature, but in a different way.

Overall, the story of Vulkano vs gfx-rs/portability isn't the best highlight of Rust evolution. Vulkano's premise was based on the availability of Vulkan on all platforms, which was developed by Vulkan Portability Initiative (the technical sub-group within Vulkan), which we (gfx-rs team) were more than just a part of - we were largely driving the initiative at that time with our investigations of the API differences, exploration of DX12, and pioneering the CTS port on macOS. So, in the big picture, Vulkano's success depended on gfx-rs team and gfx-portability success, and yet Vulkano author decided to promote MoltenVK integration and didn't pay much attention to our work (see vulkano-rs/vulkano#525).

---

Anyhow, going out of the history dive, I think my curiosity has been satisfied. Thank you! I'm looking forward to the dialog on how we can help you solve the graphics needs (in #374).

[kvark]

Small correction:

Truth is, gfx-portability was born (and operational to some extent) roughly 2 years ago, even before MoltenVK got open-sourced

MoltenVK was only announced to be open-source on GDC 2018, which is about 6 months after gfx-portability was able to run the first samples (~Sept 2017).