Generate format sizes according to the specification table

[brandonpollack23]

This table in the specification lists all formats for each version/extension.

It'd be nice for some types of descriptor generators that are generic and not stored in a single struct where we could use offset_of to generate a table with these sizes (right now i do it by hand and panic on any formats I don't use to remind me to fix later).

I currently use erupt but will migrate to ash later, when I do I could take this PR on if it isn't looked at yet.

[Ralith]

This seems useful, but I tend to be wary of features for ash itself that are outside the scope of bindings per se. Maybe something for a support crate?

[i509VCB]

Beyond format sizes, things like the numeric type would also be useful and a way to generically represent a format as an enum without the numeric type. This would be helpful for Smithay so we can have more precise DRM to Vulkan format conversions.

[trevex]

Just wanted to highlight that several libraries currently roll their own Format implementation for this very reason:

Currently vulkano generates its own formats: https://docs.rs/vulkano/latest/vulkano/format/enum.Format.html#method.block_size

Sierra (uses erupt) seems to also expose custom formats:
https://docs.rs/sierra/latest/sierra/enum.Format.html#method.description

I think it would be beneficial to the ecosystem if this information were to exist as part of ash or a supporting ash_*-crate.

[dustContributor]

It would be really nice to have this as part of ash. As an example this is what the validation layers have for dealing with formats:
https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/layers/vulkan/generated/vk_format_utils.cpp#L70

And the generator that produces the file:
https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/scripts/generators/format_utils_generator.py

It's filled with handy functions to get components, sizes, "SRGBness", etc.

I completely understand this goes beyond the scope of what you'd call "pure bindings" but it's a matter of practicality. Either ash does it once, for all formats, and properly, or every single ash user is going to roll their own spin of this kind of code, which chances are will be inferior, undocumented and error prone.

I was actually surprised there wasn't a query API for these kind of things in Vulkan already since it has been a pain point since OpenGL days.

[Ralith]

Either ash does it once, for all formats, and properly, or every single ash user is going to roll their own spin of this kind of code, which chances are will be inferior, undocumented and error prone.

I believe most ash users know in advance what formats they are working with and do not need any of this. If some community of users nonetheless finds that they do commonly need it, why not publish and share a self-contained crate for the purpose? This can explore the complex API design challenges (maybe draw on the Khronos DFD stuff) and be updated and maintained in a decoupled manner. Converting to/from ash::vk::Format values would be trivial.

[MarijnS95]

I've long thought about adding a separate crate to ash for this purpose (or implement it directly on the vk::Format type) after the new generator (#344) is getting closer to completion and generically usable to generate various independent bits of Ash (including dispatch/lookup tables for writing layers etc).

[dustContributor]

@MarijnS95 Thank you for considering it!