Unify extension module hierarchies #894
Conversation
Ralith
force-pushed
the
unified-exts
branch
2 times, most recently
from
2ac9729
to
a526d8d
Compare
|
Updated changelog. |
There was a problem hiding this comment.
That's an amazing amount of repetitive hand-written code gone from the codebase! We should've done this much sooner, specifically these duplicated bits have been a continuous source of conflicts and compiler errors during the refactors of the past week.
This is also a direction I was hoping to head into with better generator support: at some point we can start autogenerating some of these functions, and use both heuristics and config files to allow keeping manual implementations where a generator just doesn't understand the desired API.
Ralith
force-pushed
the
unified-exts
branch
4 times, most recently
from
bd54abb
to
851e297
Compare
|
Revised approach: all core and extension raw type definitions and constants are exported directly under This standardizes |
| @@ -76,6 +76,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
| - extensions/ext/ray_tracing_pipeline: Pass indirect SBT regions as single item reference (#829) | |||
| - Replaced `c_char` array setters with `CStr` setters (#831) | |||
| - `push_next()` functions now allow unsized `p_next` argument (#855) | |||
| - Flattened `ash::extensions` into `ash`, flattened `ash::vk::*` extension modules into `ash::vk`, and moved `*Fn` function pointer table structs from `ash::vk` into `ash` or the associated extension module (#894) | |||
There was a problem hiding this comment.
flattened
ash::vk::*extension modules intoash::vk
That seems slightly strange to mention as extension modules didn't exist (not even in ash::vk::*) in the latest release (they've only been introduced and resided there temporarily).
However, looks like we totally forgot to even mention that entire mod-refactor for extensions in #734.
Alas, nothing too bad, as I think we should write a proper actionable summary when publishing the 0.38 release.
…nsion wrappers In #894 we lost the ability to `Clone` the high-level wrappers, even though the underlying `*Fp` table and the `vk::Instance` or `vk::Device` handle themselves are `Clone`. Restore that behaviour.
…th 3 specialized functions Since the extension modularization in #894 this `enum ShaderInfoResult` is no longer reachable through the crate hierarchy, making it impossible for callers to match on its variants. Not that this type was ideal to begin with: the returned `enum` variant depended purely on the `info_type` parameter, leading to ugly `unreachable!()`-like unwraps in caller code when the variant should always be of the type that a caller requested. To solve both issues, create 3 instances of the `get_shader_info()` function for each of the 3 `vk::ShaderInfoTypeAMD`s that a caller can request.
…th 3 specialized functions (#901) Since the extension modularization in #894 this `enum ShaderInfoResult` is no longer reachable through the crate hierarchy, making it impossible for callers to match on its variants. Not that this type was ideal to begin with: the returned `enum` variant depended purely on the `info_type` parameter, leading to ugly `unreachable!()`-like unwraps in caller code when the variant should always be of the type that a caller requested. To solve both issues, create 3 instances of the `get_shader_info()` function for each of the 3 `vk::ShaderInfoTypeAMD`s that a caller can request.
Fixes #876.
As a bonus, this significantly reduces the amount of boilerplate required to wrap a new extension.