Separate functionality of the different versions of Vulkan into the submodules.

[Jerrody]

If you look at the erupt crate you will see this structure:
https://docs.rs/erupt/latest/erupt/#modules
vk // main module that just exports all submododules

• vk1_0
• vk1_1
• vk1_2
• vk1_3

[Ralith]

Why should we do that?

[Jerrody]

Why should we do that?

Because it's convenient to use. As an example, I use only 1.3 and I don't need to see in suggestions AccessFlags I need only AccessFlags2.

So, I can just import ash::vk1_3 (as example) and done.

[MarijnS95]

That doesn't seem to make much sense. Vulkan 1.3 builds on top of Vulkan 1.0, 1.1 and 1.2. You can't use Vulkan 1.3 in any meaningful way without touching any of the prior APIs. vkCreateInstance and vkCreateDevice anyone?

It won't work for member functions on VkDevice (presuming erupt implements such a thing like ash) unless they're stored in per-version traits, a thing ash did in the past but dropped for being generally unfriendly: #412

Now, if you had made a point of limiting the highest version to use, ie. importing just Vulkan 1.0 and 1.1 to enforce a restriction on the available API to stay compatible with Android (phones are still forced to ship with 1.1, no 1.2 allowed), that's a valid use case.

[Friz64]

In erupt, I have it that way because it wasn't complicated to set up and provides cleaner separation, you'll see a type in the docs and know "ahh, that's from Vulkan 1.2". I've never personally had a use for it in code, as one would usually use the erupt::vk module, which re-exports every Vulkan item, even extensions.

It won't work for member functions on VkDevice (presuming erupt implements such a thing like ash) unless they're stored in per-version traits, a thing ash did in the past but dropped for being generally unfriendly: #412

erupt has one unified loader for Entry, Instance and Device respectively that implements every appropriate function, so you'll even get suggestions for all extensions on top of all functions provided by core Vulkan.

[MarijnS95]

Summary: with the information from @Friz64 this is only applied sparsely in erupt (types / enums / constants) but not to functions, and the IMO debatable use-case described by @Jerrody above I don't see much if any advantage to this separaton.

If we were to do this I feel like it should be paired with a revert of #412 so that the separation is uniform across item definitions and associated functions on entry/instance/device.

@Jerrody Unless you wish to clarify your use-case or there is a popular opinion that this will improve ash in a meaningful way (consider this will be a rather large API break for everyone) I don't see anything actionable here.

[Jerrody]

@MarijnS95

API break for everyone

Actually no. For everyone code will keep work the same as before, but I don't know what to add else about this. This is for the logical separation of different editions of Vulkan.

So, if you didn't find good in my suggestion or argument I think that issue should be closed.

[MarijnS95]

Actually no. For everyone code will keep work the same as before

That's only the case when creating a vk module that reexports everything. But as said right above, doing this split for the types and modules only makes sense (in my eyes) if we also do it for all associated functions on entry/instance/device (ie. reverting #412) which is an API break (crates have to explicitly import the traits again, or import vk::*).