-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate format sizes according to the specification table #681
Comments
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? |
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. |
Just wanted to highlight that several libraries currently roll their own 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: I think it would be beneficial to the ecosystem if this information were to exist as part of |
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: And the generator that produces the file: 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. |
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 |
I've long thought about adding a separate crate to |
@MarijnS95 Thank you for considering it! |
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.
The text was updated successfully, but these errors were encountered: