hal/vk: Remove ash from the public interface

[zmerp]

Connections
#2615

Description
Removes ash from wgpu-hal public interface. ash objects are replaced with raw pointers or u64 handles.

The API has become more unsafe because it requires some pointer casting and transmutation to convert ash objects to pointers (and vice versa). Some methods got duplicated (<method> + <method>_inner) for ergonomics and efficiency.

I included some changes unrelated to the visibility of the ash crate. There are two new methods for improving the usability and correctness of the API: I added a Instance::required_layers() and merged some code into a single Device::required_device_capabilities() to reduce the API surface.

The most controversial change is that now the user does not pass extensions anymore to create the Instance and Device, the extension list is calculated internally in wgpu and the user just needs to pass InstanceFlags or Features and Limits. The user still has to create the raw instance and device using the required_*() methods. This change has not much effect in terms of safety but it makes sure that invariants are held at the wgpu code level, Instance and Device created from wgpu-core or from raw pointers should look as similar as possible.

Testing
Ergonomics evaluation with this code. No runtime tests yet.

[kvark]

Looks very promising, great work!

[kvark]

does this still need to be public? strange given the "_inner" suffix

[zmerp]

That was a mistake, thanks. I'm going to finish some tests on the weekend.

[jimblandy]

Given @MarijnS95's comment that Ash would not be making as many breaking changes in the future as it has in the recent past, is this change still desirable?

It's true that having untyped pointers in the API would make the types in wgpu's API independent of the underlying Vulkan bindings. But in practice, wgpu's own code certainly knows which Vulkan API it's using, and wgpu's user had better be using the same one, or else it's chaos. So it doesn't seem like it gets you anything in practice, other than loose typing.

Asked another way: What could developers do if wgpu accepted an untyped raw pointer that they couldn't do if it accepted a typed pointer?

[zmerp]

@jimblandy As you may have realized I stopped working on this PR since it's controversial and I don't have enough elements to prefer one or the other way.

But in practice, wgpu's own code certainly knows which Vulkan API it's using, and wgpu's user had better be using the same one, or else it's chaos

This PR uses raw Vulkan pointers and handles which are 100% independent from the ash version. There is no fear of undefined behavior because of an ash version mismatch.

[MarijnS95]

@jimblandy We'll probably still be making more breaking changes, just that there won't be any new breaking release any time soon: we'll save up all the breaking changes for much bigger releases going forward so that the version bumps aren't such a hurdle due to a tiny breaking API change in an obscure extension, for example.

Regarding eventually supporting alternative Vulkan wrappers, the author of Erupt is working towards merging with ash so that we don't have any ecosystem divergence for something "as simple as" an "unopinionated" Vulkan wrapper crate: ash-rs/ash#344 (comment) / https://gitlab.com/Friz64/erupt/-/issues/56.

[jimblandy]

This PR uses raw Vulkan pointers and handles which are 100% independent from the ash version. There is no fear of undefined behavior because of an ash version mismatch.

Okay, I'd misunderstood the situation. The idea here was that, regardless of what Rust crate one is using to get at the system's Vulkan library, as long as you're using one of the "thinnest possible Rust wrapper" crates, their handle types are functionally equivalent: they're newtypes or type aliases for the same Vulkan handles.

So the idea of this PR was that wgpu-hal's public type signatures shouldn't really care which wrapper you're using. Exposing ash just prevents people from using (uh... looks up other Vulkan crates) erupt, even though the handles are identical.

Since we're not sure this is the way we want to go, I'm going to close this PR for now. If circumstances change, we can re-open it.

[zmerp]

This PR also did some general correctness improvements to the API, I can open another PR just for those changes.

[MarijnS95]

@jimblandy Ash, and probably also erupt, use newtypes instead of typedefs to prevent accidentally passing the wrong objects or handles into the wrong places. I don't understand the "fear of undefined behavior because of an ash version mismatch" because ash's Vulkan types will always be of equal representation to the "C struct" in the Vulkan spec, otherwise it would be unusable either way 🤷

The only thing we'll change API-wise is how users interact with the crate. For example function signatures of "wrapper" functions that juggle borrows and slices into raw pointers and sizes, the struct builders, lifetime management, function loaders etc.

@zarik5 Recommended to always separate unrelated changes out into multiple PRs. That way everything gets the visibility it deserves, won't be overlooked in review, and small changes are much quicker to review and merge 😁

[jimblandy]

I don't understand the "fear of undefined behavior because of an ash version mismatch" because ash's Vulkan types will always be of equal representation to the "C struct" in the Vulkan spec

Yes, this was my misunderstanding. Then I realized what I'd gotten wrong, and wrote:

as long as you're using one of the "thinnest possible Rust wrapper" crates, their handle types are functionally equivalent

which is, I believe, what you're saying.

[jimblandy]

This PR also did some general correctness improvements to the API, I can open another PR just for those changes.

Thank you!

[MarijnS95]

I don't understand the "fear of undefined behavior because of an ash version mismatch" because ash's Vulkan types will always be of equal representation to the "C struct" in the Vulkan spec

Yes, this was my misunderstanding. Then I realized what I'd gotten wrong, and wrote:

I wasn't entirely clear here, but this question is directed at @zarik5 whom I quoted there, as you seem to be wondering/confused by the same sentence.

as long as you're using one of the "thinnest possible Rust wrapper" crates, their handle types are functionally equivalent

which is, I believe, what you're saying.

Yes, if they're layout-identical with the Vulkan API definition they're identical among Rust crates too. That won't mean they're ergonomic to use if the wrapper library in question uses newtyping instead of type aliases. In the end wgpu transmutes to untyped (raw) pointers and u64 handles, only for the caller to transmute them back to their API "of choice" (which will be ash after the merger).