* Update Vulkan-Headers to 1.3.270
* Update Vulkan-Headers to 1.3.271
* extensions/nv/low_latency2: Support extension revision 2
Upon request the VK_NV_low_latency2 spec and API has been updated to move
the count pointer from the `vkGetLatencyTimingsNV()` function to
the `vkGetLatencyMarkerInfoNV` struct where the array pointer already
resided.
This got uncovered when it was realized that the `latency_marker_info`
argument isn't an array at all (which the original design of this
extension suggested), but a pointer to a single struct that _contains_
a pointer to an array, with the length passed as a separate argument to
the function instead.
The move of this count argument to a struct field - together with proper
array length annotations - gets our generator to automatically emit a
setter based on a slice argument.
In an identical fashion to commit 84624fd ("ray_tracing_pipeline:
Pass SBT regions as reference instead of slice (#350)")
`cmd_trace_rays_indirect()` also only needs a pointer to a single
`StridedDeviceAddressRegionKHR` structure. After all no length is ever
passed to the API anywhere, and this could also lead to users passing
empty slices, or passing too many elements that are never used.
Clear up the confusion by replacing the slice argument with a direct
borrow of the struct.
Some links were still pointing to the (moved) `MaikKlein/ash` repo,
instead of the new shared `ash-rs/ash` repository under this
organisation, GitHub still provides a redirect, but we should aim to
provide the correct link from the get-go. Only the gitter channel
remains as it was impossible to get the room to be renamed. The
`ash-rs/ash` channel exists but there is currently no activity.
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.
