Merge latest ash changes into the nv-low-latency2 branch
#1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using a `git` reference on this repo, `cargo` will unnecessarily clone the `Vulkan-Headers` submodule (which is only needed by maintainers together with the `generator`). By setting the update mode to `none` (https://git-scm.com/docs/gitmodules#Documentation/gitmodules.txt-submoduleltnamegtupdate) this is disabled, and `git submodule update` will now also no longer fetch/clone/update the repository unless `--checkout` is used (https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt-checkout). I.e. running `cargo update` on a repo with a `git` dependency on `ash`: Updating git repository `https://github.com/ash-rs/ash` Skipping git submodule `https://github.com/KhronosGroup/Vulkan-Headers` due to update strategy in .gitmodules
…809) 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
Even though we don't have many dependencies, our GitHub Actions are getting severely out of date and are best updated to the latest version. Let dependabot help us with this, together with the few `cargo` crate dependencies that we have (mainly in examples).
…812) Bumps [actions/checkout](https://github.com/actions/checkout) from 1 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v1...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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.
[Dependabot complains] that:
the binary target name `examples` is forbidden, it conflicts with with cargo's build directory names
And fails to provide dependency upgrades for Rust code. Fix that by
renaming the folder and crate to `ash-examples`.
[Dependabot complains]: https://github.com/ash-rs/ash/network/updates/748770724
Updates the requirements on [vk-parse](https://github.com/krolli/vk-parse) to permit the latest version. - [Commits](krolli/vk-parse@vk-parse-0.10.0...vk-parse-0.12.0) --- updated-dependencies: - dependency-name: vk-parse dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on [itertools](https://github.com/rust-itertools/itertools) to permit the latest version. - [Changelog](https://github.com/rust-itertools/itertools/blob/master/CHANGELOG.md) - [Commits](rust-itertools/itertools@v0.10.0...v0.12.0) --- updated-dependencies: - dependency-name: itertools dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on [bindgen](https://github.com/rust-lang/rust-bindgen) to permit the latest version. - [Release notes](https://github.com/rust-lang/rust-bindgen/releases) - [Changelog](https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md) - [Commits](rust-lang/rust-bindgen@v0.64.0...v0.69.1) --- updated-dependencies: - dependency-name: bindgen dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Since a few Rust versions `cargo` complains: warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"` Avoid that by setting the resolver for the virtual manifest to `"2"` explicitly.
…gle item (#829) 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.
Updates the requirements on [syn](https://github.com/dtolnay/syn) to permit the latest version. - [Release notes](https://github.com/dtolnay/syn/releases) - [Commits](dtolnay/syn@1.0.0...2.0.39) --- updated-dependencies: - dependency-name: syn dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* 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.
…831) It is a common operation to read and write NUL-terminated C string in the Vulkan API, yet the only helpers for that were thus far open-coded in the `Debug` printing implementations. Move them to separate functions that are exposed to the user, in hopes of helping them no longer misunderstand NUL-terminated strings (see e.g. #830). Important to note is that the array-copy for a static-sized `c_char` array has also been replaced with a `CStr` wrapper: this forces the user and our implementation to have a NUL-terminator at the end of the string, and the setter returns `Err()` when the given `CStr (with NUL-terminator) is too large for the static-sized array it has to be written to.
* Convert `mem::zeroed()` / `0` to `MaybeUninit::uninit()` As noted in #792 changes like this might help us more strictly identify and validate that the argument in question is only relevant as an output argument (i.e. structs with `sType` are read by the function call, even if the caller strictly expects return values there, so that it can fill in multiple structures in a `pNext` chain, and must hence be `Default`- initialized). * Use uninit `Vec`s with late `set_len()` call instead of zero-initialization * Use `uninit()` instead of `-1` for file descriptors * Introduce `set_vec_len_on_success()` helper for `Vec::with_capacity()`
…fetimed slice (#841) In essence this builder function needs to adhere to two rules: 1. No ref-after-free: the slice must outlive (uses of) the builder object; 2. No aliasing: the slice cannot be (im)mutably used while it is mutably borrowed within a live builder object. These two rules have been tested and are satisfied by the given builder implementation. Without this change `timings` seems to be borrowing itself, hence is not allowed to be used after it has been temporarily mutably borrowed inside the builder, even after that builder was dropped. Thus defeating the purpose of this "getter" API via a struct. Without the `.cast()`, because mutable raw pointers are invariant (i.e. there is no subtyping relationship) the compiler complains about requiring `self` to outlive `timings` instead, which does not satisfy the two rules above.
…rapper (#746) Certain structs contain sized character arrays that are converted to `CStr` for convenient accss to the user and our `Debug` implementation using unsafe `CStr::from_ptr(...as_ptr())`. There is no need to round-trip to a pointer and possibly read out of bounds if the NUL-terminator index (string length) is instead searched for by the newly stabilized `CStr::from_bytes_until_nul()` fn since Rust 1.69 (which panics if no NUL-terminator is found before the end of the slice). Unfortunately `unsafe` is still needed to cast the array from a `c_char` (`i8` on most platforms) to `u8`, which is what `from_bytes_until_nul()` accepts.
All structs are marked as `Copy`, and builders move `self` for a convenient builder pattern directly on `default()` (using `&mut` requires requires first keeping the instance alive in a `let` binding). This however leads to builder functions accidentally moving a copy of `self`, mutating it, and dropping the result directly when the caller did not consume the returned value in ad-hoc field updates, in turn leaving the author confused why their code compiles without warnings while the struct was not updated. Annotating all Vulkan structs with `#[must_use]` should at least give them an idea why.
Rust 1.75 has once again gotten a bit more complete/strict when linting code. `.get(0)` is now recommended to be replaced with `.first()`, and needless glob reexports are equally denied (the modules in question either contain macros which are already reexported via `#[macro_export]`, or contain `impl` blocks exclusively which cannot be referred to as item paths either).
…rays (#858) Upstream Vulkan is okay with the request to annotate static arrays with a `len="structField"` annotation when the size of the static arrary is bounded by a value at runtime. This allows us to generate more convenient builder functions that copy slices into the target "builder" struct while _also_ updating the length, rather than forcing the caller to move an array of the desired length with zeroed elements and setting the length field separately. In addition provide a safe getter (and use it in the `Debug` implementation) to return a slice view containing only valid items per the length field. As with strings this is only possible for static-sized arrays as we can never safely dereference a random pointer.
#860) While this function is already marked `unsafe` to represent cases where an invalid pointer might be dereferenced, it should at least be obvious to the caller that there is a real chance for `NULL` pointers in these `CStr` getters, which will now be returned as `None`. This function won't be used in `Debug` now as the dereference operation is still `unsafe`. The `_as_c_str()` getters for static arrays is left untouched, as the data is read directly from the known-valid struct here.
|
The CI failure is: ash-rs#863 - can be ignored, will be fixed once that is merged. |
|
Let's do https://github.com/EmbarkStudios/wim-app/pull/11527 instead. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.