Move vk.rs to new vulkan-sys crate

[TimDiekmann]

Closes #91

---

This change is 

[MaikKlein]

Do we want vk-sys to start from version 0.24.3. Shouldn't the version be separate from ash?

[TimDiekmann]

What's about the current header version, which is used for generating vk.rs?

[Ralith]

Changes to the generator will inevitably force the version number to diverge from upstream's sooner or later.

On another subject, I wonder if it would be appropriate to grab a more generic name like vulkan-sys?

[TimDiekmann]

vulkan-sys isn't used atm. For users who don't use ash but raw vulkan, it doesn't lead to confusion.

[Ralith]

My thought was that, being a raw binding, it's sufficiently un-opinionated to be of use by others, e.g. vulkano. Not much point in factoring out the -sys part if it's never going to be used by anyone else, after all.

[MaikKlein]

Sorry I meant ash-sys above, I think ash-sys is fine but I really don't have any strong opinions about the name.

I still think the version should be separate and that means the workspace dependency should also require an explicit version.

[Ralith]

I really don't think using the vulkan.h version makes sense, unless we want to commit to never, ever making another breaking change to the structure of the output.

[TimDiekmann]

I really don't think using the vulkan.h version makes sense, unless we want to commit to never, ever making another breaking change to the structure of the output.

I think @MaikKlein has to decide this.

Pro:

• It's very transparent, which specs can be used
• breaking change will be rarely when generator will be merged to master, vulkan-sys won't be published until then (I guess?)

Con:

• If the time span between two spec updates is long, a critical update may take longer

[Ralith]

It's very transparent, which specs can be used

It's perfectly legal to use a newer binding with an older vulkan implementation, and it will be immediately obvious (and easily corrected) if the binding doesn't have something you need. This also breaks down permanently the first time a breaking generator change happens.

breaking change will be rarely when generator will be merged to master

However rare breaking changes to the behavior of the generator are, they will almost certainly happen inevitably, rendering the whole endeavor futile.

[MaikKlein]

Here are my thoughts:

Using the vulkan version is well indented, but as @Ralith said, will be futile.

I think the name ash-sys is better over vulkan-sys because it is not a alone standing library. If ash needs something, ash-sys has to be changed. It is mostly there for some people who don't care about the higher level stuff that ash provides. I am actually not sure if anyone wants to use ash-sys.

With explicit versioning I mean starting from 0.1 for ash-sys, and use explicit versions in the toml file like, ash-sys = {version = "0.1", path = "../ash-sys" }

One thing I think is a bit weird is how we would mark breaking changes in a semver manner. ash uses ash-sys the vk.rs file, and exports the functionality.

Now if ash-sys does a breaking change, like renaming some constants, then ash should also get a version bump, because otherwise some code will break, and this is not caught at compile time because ash pretty much doesn't use constants at all. It seems easy to accidentally break semver.

Is ash-sys really something we want to do? Or does it just add unnecessary maintenance?

[Ralith]

I'm a bit fuzzy on the motivation too. It would be aesthetically pleasing for the various vulkan crates to agree on a common -sys layer (and occasionally useful for type-safe interop, e.g. in windowing and VR libraries), but perhaps we should get buy-in from the other maintainers before investing effort in it.

[TimDiekmann]

Rerenamed to ash-sys and changed version to 0.1. Now it's up to @MaikKlein to merge or close it. Please do not hesitate to simply close the PR if you wish.

[kvark]

In general, gfx-backend-vulkan would like to use a lower level crate to do things.
We'd also want to ask @tomaka if they'd consider moving Vulkano to ash-sys, if it's superior to the current vk-sys.

[MaikKlein]

ash-sys is definitely a bit opinionated and is just an implementation detail for ash. vk-sys is very similar to ash-sys. Ash just creates separate function pointer structs for the various extensions. Also the naming scheme is different.

The biggest benefit is that ash-sys is generated and therefore will include all the new stuff. ash-sys also has real bitflags, more derives (also not complete), most things also have a default implementation.

const names are currently still missing but will be implemented very soon and the function pointer loading will become similar to vulkano, where null pointers will resolve into a function that always panics. At the moment ash just panics if anything fails to load.

I'll merge this PR before the next version of ash is released.

[tomaka]

also has real bitflags, more derives (also not complete)

That's really opinionated, but I don't really like that.
The way I see FFI bindings is that they should just be function pointers and constants, and that's it. Any trait implementation for example makes the bindings "unpure", as it can possibly lead to disagreements over how the trait implementation should behave.

However that's not a strong enough argument to not switch vulkano to ash-sys, I guess.

[Ralith]

@tomaka's complaints could be addressed by generating two separate files: one for the sys crate which contains nothing but type and constant definitions, and another that implements the idiomatic rust wrappers, strong types, loading, etc. and goes in the ash crate.

[MaikKlein]

@tomaka's complaints could be addressed by generating two separate files: one for the sys crate which contains nothing but type and constant definitions, and another that implements the idiomatic rust wrappers, strong types, loading, etc. and goes in the ash crate.

I am okay with this. We could generally try to make everything more configurable, for example allow different naming schemes etc

Although this probably will require some refactoring.

My only concern is that we might end up with too many versions of ash-sys, which might not be compatible with each other.

[Ralith]

To be clear, I'm not proposing multiple versions of the -sys crate, just splitting what is currently vk.rs into two parts: the sys crate, which is absolutely nothing but a faithful FFI binding, and a module in the ash crate, which provides the zero-cost safer wrappers we know and love by wrapping parts of the sys crate as needed.

[Thomspoon]

Has there been any progress on this? As a new customer of Vulkan, it's hard to jump into an API that abstracts out so much. It'd be nice to have a raw Vulkan API that doesn't require reading complex macros or building a bunch of wrapper structs.

[Ralith]

I don't think ash's API requires you to use macros or construct wrapper structs at any point.

[Thomspoon]

I'm talking about using raw vulkan generator. If you want to use raw vk calls, you can follow suit to what vulkano and ash are doing, but I think it's a little complicated than just loading the library, constructing the pointer and being good to go. I don't really want to start with Ash or Vulkano, I'd rather see the footguns for myself.

[Ralith]

To be clear, ash is nothing like vulkano; there is practically no abstraction, just trivial (but convenient) syntax sugar. It's almost identical to what you'd write in C.

[Thomspoon]

Gotcha, maybe I'm worrying about nothing. I get antsy when I see issues like: #100, where it looks like an abstraction that won't let you use the raw functionality of Vulkan. Thank you for the responses.

[Ralith]

Yeah, issues like that are rare, and are considered to be bugs.