This parameter is not only used for the length of `pImageInfo`,
`pBufferInfo` or `pTexelBufferView`, but also matching the value
of `dataSize` when `VkWriteDescriptorSetInlineUniformBlock` is
appended in `pNext`, or the value of `accelerationStructureCount`
when `VkWriteDescriptorSetAccelerationStructureKHR` is in `pNext`.
Having the count setter directly avaialble makes builder code more
natural, instead of having to use a `mut` variable and manually assign
`.descriptor_count = xx.len();` afterwards.
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkWriteDescriptorSet.html
* Update Vulkan-Headers to 1.3.255
* Update Vulkan-Headers to 1.3.257
* Update Vulkan-Headers to 1.3.258
* Update Vulkan-Headers to 1.3.259
* Update Vulkan-Headers to 1.3.260
* Update Vulkan-Headers to 1.3.252
* Update Vulkan-Headers to 1.3.253
* Update Vulkan-Headers to 1.3.254
* vk/platform_types: Add `_screen_buffer` type for QNX
* Update Vulkan-Headers to 1.3.247
* Update Vulkan-Headers to 1.3.248
* Update Vulkan-Headers to 1.3.249
* Update Vulkan-Headers to 1.3.250
* Update Vulkan-Headers to 1.3.251
We don't mark any of the extern calls to Vulkan function-pointers safe
except for a few `Entry` functions. Their safety contract was easy to
validate, but now that we exposed a constructor function to let the user
provide function pointers in the form of `Entry::from_parts_1_1()` it is
no longer safe to assume that we are calling the function that adheres
to the contract specified in the Vulkan reference.
Because we don't rigorously do this validation and safe-marking anywhere
else either, mark these function calls as `unsafe`.
Related discussion chain: https://github.com/ash-rs/ash/pull/748#discussion_r1186794284
* ash/device: Allow building device from handle+fns
Adds a constructor to build a device from a handle + functions.
Helps with interoperability with other vulkan wrappers
* ash/instance: Allow building instance from handle+fns
Adds a constructor to build an instance from a handle + functions.
Helps with interoperability with other vulkan wrappers
* ash/entry: Allow building entry from handle+fns
Adds a constructor to build an entry from a handle + functions.
Helps with interoperability with other vulkan wrappers
* changelog: Document #748 addition of `from_parts` constructors
Generate templated builder setters for fields taking an `objecttype`
We already do this for hand-written extension functions but can now also
implement it for setters since `vk_parse` fields are available within
the builder generator code: when a field refers to another field for
setting its `objecttype`, that `VkObjectType` field setter is omitted
and instead assigned when the object is set, based on a type generic
that implements the `Handle` trait instead of an untyped `u64`.
These functions don't contribute anything and should be removed to clean
up the `features` and `extensions` files, while now also not showing in
the documentation anymore. The structs remain in place for associated
constants but are replaced with true unit-like structs (no curly
brackets anymore), and unneeded `unsafe impl Send/Sync` are removed as
well.
As these `load()` functions have been removed from the empty
feature-levels on `Entry` and `Device` as well, rather than
instantiating the unit structs and returning those the fields and
`fp_vX_X()` getters have been removed entirely.
Xlib defines `Display` as follows:
typedef struct _XDisplay Display;
And then always references this type as a pointer to it, e.g. `Display
*`. The same happens in `ash`, where `Display` is only ever referenced
as a raw pointer via `*mut Display`, so making `Display` itself a type
alias to `*mut c_void` is wrong and confusing. Switch it back to a
`c_void` to match the forward-declared (but otherwise undefined) `struct
_XDisplay`.
Looks like #630 typo'd the argument for `DeviceGroupCreation::new()` by
unnecessarily requiring a move (`Clone`) of `Entry` just to call
`get_instance_proc_addr()` on it. Replace this with a borrow to match
all other extensions.
* extensions/khr: Take the remaining `p_next`-containing structs as `&mut`
Version 2 of `get_physical_device_surface_capabilities` and the matching
`vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType`
and `pNext` field to allow extending the original query with additional
data via extension structs. However, this API when introduced in #530
only returns the `default()`-initialized struct making it just as
constrained as `get_physical_device_surface_capabilities()`. Solve this
by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar
API.
And just like this, do the same for the remaining:
- `AccelerationStructure::get_acceleration_structure_build_sizes()`
- `ExternalMemoryFd::get_memory_fd_properties()`
- `ExternalMemoryWin32::get_memory_win32_handle_properties()`
In case these structs get extended somewhere down the line, which the
Vulkan API allows for.
* extensions/khr/acceleration_structure: Use `mem::zeroed()` in place of `vk::AccelerationStructureCompatibilityKHR::default()`
This helper function isn't consistently implemented across most
extension wrappers, and promotes bad Vulkan patterns by not making it
obvious to the caller that `get_physical_device_properties2()` can and
should be used to fill multiple properties structs at once.
* Update Vulkan-Headers to 1.3.239
* Update Vulkan-Headers to 1.3.240
* Upgrade to `bindgen 0.63` and `vk-parse 0.9`
Updates cause no semantic changes in usage nor generated output.
* generator: Support new `deprecated` attribute
* Update Vulkan-Headers to 1.3.241
* generator: Emit `#[deprecated]` annotation for type members (struct fields)
* Update Vulkan-Headers to 1.3.242
* Update Vulkan-Headers to 1.3.243
* Update Vulkan-Headers to 1.3.244
`CStr::from_bytes_with_nul_unchecked` is `const`-stable since Rust 1.59
which is already required for `ash` so it is high time to finally turn
these inlined `name()` functions into associated constants (which is a
breaking change in itself that cannot be backported).
Commit c66db26 ("device: Replace `query_count` parameter in
`get_query_pool_results` with `data.len()` (#644)") removed this
parameter in favour of using `data.len()` to make it more obvious to use
an appropriate element type that matches the kind of request (see also
#639) so that the stride is filled in correctly, but it was not
mentioned in the changelog yet.
