Explain when to choose vulkania over ash in the readme

[mickvangelderen]

Hey there, I'm starting a new project where I want low level access to the vulkan API and I'm trying to figure out what library to use.

So far I've found:

• ash (most common)
• vulkania
• vulkan-bindings (unmaintained ~4 years)

It would be great to get a rough idea of what sets vulkania apart from the README.

[cryscan]

I find that there was a detailed explaination about this crate vs. ash in #204.

[mickvangelderen]

Thanks, that's helpful!

[KyleMayes]

I'm not sure there's a big reason to prefer this crate over ash.

As was touched on in #204, I primarily created this crate (and the associated tutorial) since I thought it would be a fun project and would teach me something about low-level graphics programming. It succeeded on those fronts, I think I've learned quite a bit and still enjoy maintaining this crate (glances nervously at some of my other repos that I've been neglecting).

On the other hand, I suppose by this crate existing at all, I am implicitly saying that I think it offers something beyond, or at least different than, what ash offers.

I think the primary reason to pick vulkanalia is that it stays more up-to-date with the bleeding edge Vulkan features. Usually vulkanalia supports new Vulkan extensions within a few weeks of them being added to Vulkan since vulkanalia is almost entirely generated from the Vulkan XML specification. Sometimes much sooner if I'm quick to hit the merge button (and my code generator doesn't break. Maybe I should start auto-merging Vulkan definition PRs if the tests pass... 🤔

But if you don't care about the latest extensions being shoved into Vulkan, ash is much more battle-tested, though I'm not sure how much that matters since both crates are mostly just thin wrappers around Vulkan.