* Error: vkCreateDevice: VK_KHR_portability_subset must be enabled [...]
* Error: Attempting to create a VkDevice from a VkPhysicalDevice which is from a portability driver without the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit in the VkInstanceCreateInfo flags being set and the VK_KHR_portability_enumeration extension enabled.
* Constify generated extension names
* Constify hand-written extension names
* Make ash-window list extensions as &[*const c_char]
This alters enumerate_required_extensions() to return the same type that
is expected by vk::InstanceCreateInfoBuilder::enabled_extension_names(),
allowing simple Vulkan apps to omit the boilerplate of mapping to an
intermediate Vec<*const c_char>.
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
* Simplify .map().flatten().next() and .filter_map().next() to .find_map()
* Avoid unnecessary closures for cheap expressions
* Use character instead of string for replacement pattern
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
These two conversions occur all the time in Vulkan applications. For
example, Extent2D -> Extent3D occurs whenever you need to make an image
the same size as a surface and Extent2D -> Rect2D occurs whenever you
fill out a scissors or render area from a surface resolution.
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
When the misleading `all()` function was removed in #478 it also made
all color components for `ColorComponentFlags` significantly more
verbose to write, see #536.
These allocations and runtime assertions can all be replaced with a
`CStr` directly wrapping a binary-string literal, as long as it is
null-terminated.
On platforms like Android strings use `u8` as character-type instead of
`i8` - using the appropriate `c_char` type hides this discrepancy and
allows the examples to compile for all platforms.
As per the readme `.build()` should only be called as late as possible,
and only if absolutely necessary; such cases include slices that are
passed directly to functions. More precisely, such build calls and the
creation of temporary slices should happen inside the same expression as
the function call to be sound and completely lifetime-checked.
This pattern of `&[my_builder.build()]` is however not possible when
constructing intermediary Vulkan objects that reference the slice. In
the first place this slice goes out of scope after the expression that
creates the Vulkan object, which is caught and disallowed by rustc
(unless this expression itself ends in `.build()`, which is completely
unsound as it makes rustc unable to validate this lifetime dependency).
In the second place - and as is most relevant for this patch that
removes `.build()` calls that were not surrounded by temporary slice
constructors - said expression drops the lifetime checks on anything
held by `my_builder` which _could_ go out of scope before the newly
constructed Vulkan object is used, resulting yet again in Undefined
Behaviour.
Fortunately, for slices of size 1 which are typical in Vulkan,
`std::slice::as_ref` exists which is analogous to taking a pointer to an
object and considering it an array of length 1 in C(++). This maintains
the lifetime through `Deref` and makes rustc able to fully check all
lifetimes and prevent unsound code.
Albeit improving overall consistency, the `&[my_builder.build()]`
pattern is not substituted in aforementioned Vulkan function-call
expressions as that is considered "extraneous" [1] and demonstrates the
various ways to safely construct Vulkan objects for the observant reader.
[1]: https://github.com/MaikKlein/ash/pull/506#discussion_r762630648
The `all()` function only represents bitflags known in the core of
Vulkan; it omits all bits added by extensions making this function
unrepresentative and has hence been scheduled for removal for quite some
time to get rid of the confusion it causes.
Alternatively the generator could be taught to collect bitflags added by
extensions, but new extensions get added over time skewing available
values in ash versus the current driver/environment. This makes the
value from `all()` unreliable and fragile at best.
`-` and `-=` (`sub()` and `sub_assign()`) are also controversial by
nature since the underlying value represents an integer but the
implemented math uses bitwise operators. This is a confusing design
pattern and the caller better replaces their uses - if any at all - with
`foo &= !BAR`.
* Mark EntryCustom::new_custom as unsafe
Passing a badly-behaved `load` function can invoke undefined behavior.
* Document required feature for Entry
* Support linking Vulkan directly
This is the preferred pattern in most environments when an application
cannot function without Vulkan, as it saves the libloading dependency,
eliminates an error case, and makes the Vulkan dependency visible to
the OS.
* Rename libloading feature to "loaded"
* Link by default
* Guide users towards linking the loader directly
* Remove unnecessary error type
InstanceError::LoadError was never constructed.
* Unify entry types
Simplifies the interface and allows a bunch of code to become
monomorphic.
* generator: Add edegecases for broken Video extension enum variants
* Replace deprecated `make_version()` with `make_api_version()`
* generator: Use the same predicate for push_next and its traits
Some structs turn out to be root structs when their name is not in the
`root_structs` set, even when they themselves extend another struct.
This was already taken care of for `push_next` which is emitted in this
situation, but the trait referenced by `push_next`'s `T` bound is still
relying on the `extends` field to not exist in `vk.xml` at all, leading
to it not being generated despite `push_next` needing it.
Fixes: 215511f ("Implement ExtendXXX for multiple root create infos if
there are more than 1")
* Update Vulkan-Headers to 12.175
* generator: Generate low-level structs with bindgen (for vk_video)
According to specs for Device Memory (section 10.2), memory types are
topologically sorted by their property flags so the two-pass memory
type selection is unnecessary.
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
According to specs for vkGetPhysicalDeviceSurfaceFormatsKHR(), at least
one surface format must be returned, and returned formats must not be
VK_FORMAT_UNDEFINED.
* Fix literals in vk.rs
* Address all the other clippy lints in ash
* Module level clippy lint
* More lints
* Make hashmaps generic for clippy
* Remove unused macro import
Load the example shader and texture files with `include_bytes!` so
that they can be run from the root project directory. Previously,
`cargn run --bin <EXAMPLE>` could only be run from the `examples`
directory.
