Update wgpu-types requirement from 0.20 to 22.0

[dependabot[bot]]

Updates the requirements on wgpu-types to permit the latest version.

Release notes

Sourced from wgpu-types's releases.

v22.0.0 (Our first major version release!)

Our first major version release!

For the first time ever, WGPU is being released with a major version (i.e., 22.* instead of 0.22.*)! Maintainership has decided to fully adhere to Semantic Versioning's recommendations for versioning production software. According to SemVer 2.0.0's Q&A about when to use 1.0.0 versions (and beyond):

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

It is a well-known fact that WGPU has been used for applications and platforms already in production for years, at this point. We are often concerned with tracking breaking changes, and affecting these consumers' ability to ship. By releasing our first major version, we publicly acknowledge that this is the case. We encourage other projects in the Rust ecosystem to follow suit.

Note that while we start to use the major version number, WGPU is not "going stable", as many Rust projects do. We anticipate many breaking changes before we fully comply with the WebGPU spec., which we expect to take a small number of years.

Overview

A major (pun intended) theme of this release is incremental improvement. Among the typically large set of bug fixes, new features, and other adjustments to WGPU by the many contributors listed below, @​wumpf and @​teoxoy have merged a series of many simplifications to WGPU's internals and, in one case, to the render and compute pass recording APIs. Many of these change WGPU to use atomically reference-counted resource tracking (i.e., Arc<…>), rather than using IDs to manage the lifetimes of platform-specific graphics resources in a registry of separate reference counts. This has led us to diagnose and fix many long-standing bugs, and net some neat performance improvements on the order of 40% or more of some workloads.

While the above is exciting, we acknowledge already finding and fixing some (easy-to-fix) regressions from the above work. If you migrate to WGPU 22 and encounter such bugs, please engage us in the issue tracker right away!

Major Changes

Lifetime bounds on wgpu::RenderPass & wgpu::ComputePass

wgpu::RenderPass & wgpu::ComputePass recording methods (e.g. wgpu::RenderPass:set_render_pipeline) no longer impose a lifetime constraint to objects passed to a pass (like pipelines/buffers/bindgroups/query-sets etc.).

This means the following pattern works now as expected:

let mut pipelines: Vec<wgpu::RenderPipeline> = ...;
// ...
let mut cpass = encoder.begin_compute_pass(&wgpu::ComputePassDescriptor::default());
cpass.set_pipeline(&pipelines[123]);
// Change pipeline container - this requires mutable access to `pipelines` while one of the pipelines is in use.
pipelines.push(/* ... */);
// Continue pass recording.
cpass.set_bindgroup(...);

Previously, a set pipeline (or other resource) had to outlive pass recording which often affected wider systems, meaning that users needed to prove to the borrow checker that Vec<wgpu::RenderPipeline> (or similar constructs) aren't accessed mutably for the duration of pass recording.

Furthermore, you can now opt out of wgpu::RenderPass/wgpu::ComputePass's lifetime dependency on its parent wgpu::CommandEncoder using wgpu::RenderPass::forget_lifetime/wgpu::ComputePass::forget_lifetime:

fn independent_cpass<'enc>(encoder: &'enc mut wgpu::CommandEncoder) -> wgpu::ComputePass<'static> {
    let cpass: wgpu::ComputePass<'enc> = encoder.begin_compute_pass(&wgpu::ComputePassDescriptor::default());
    cpass.forget_lifetime()
}

⚠️ As long as a wgpu::RenderPass/wgpu::ComputePass is pending for a given wgpu::CommandEncoder, creation of a compute or render pass is an error and invalidates the wgpu::CommandEncoder.

... (truncated)

Changelog

Sourced from wgpu-types's changelog.

22.0.0 (2024-07-17)

Overview

Our first major version release!

For the first time ever, WGPU is being released with a major version (i.e., 22.* instead of 0.22.*)! Maintainership has decided to fully adhere to Semantic Versioning's recommendations for versioning production software. According to SemVer 2.0.0's Q&A about when to use 1.0.0 versions (and beyond):

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

It is a well-known fact that WGPU has been used for applications and platforms already in production for years, at this point. We are often concerned with tracking breaking changes, and affecting these consumers' ability to ship. By releasing our first major version, we publicly acknowledge that this is the case. We encourage other projects in the Rust ecosystem to follow suit.

Note that while we start to use the major version number, WGPU is not "going stable", as many Rust projects do. We anticipate many breaking changes before we fully comply with the WebGPU spec., which we expect to take a small number of years.

Overview

A major (pun intended) theme of this release is incremental improvement. Among the typically large set of bug fixes, new features, and other adjustments to WGPU by the many contributors listed below, @​wumpf and @​teoxoy have merged a series of many simplifications to WGPU's internals and, in one case, to the render and compute pass recording APIs. Many of these change WGPU to use atomically reference-counted resource tracking (i.e., Arc<…>), rather than using IDs to manage the lifetimes of platform-specific graphics resources in a registry of separate reference counts. This has led us to diagnose and fix many long-standing bugs, and net some neat performance improvements on the order of 40% or more of some workloads.

While the above is exciting, we acknowledge already finding and fixing some (easy-to-fix) regressions from the above work. If you migrate to WGPU 22 and encounter such bugs, please engage us in the issue tracker right away!

Major Changes

Lifetime bounds on wgpu::RenderPass & wgpu::ComputePass

wgpu::RenderPass & wgpu::ComputePass recording methods (e.g. wgpu::RenderPass:set_render_pipeline) no longer impose a lifetime constraint to objects passed to a pass (like pipelines/buffers/bindgroups/query-sets etc.).

This means the following pattern works now as expected:

let mut pipelines: Vec<wgpu::RenderPipeline> = ...;
// ...
let mut cpass = encoder.begin_compute_pass(&wgpu::ComputePassDescriptor::default());
cpass.set_pipeline(&pipelines[123]);
// Change pipeline container - this requires mutable access to `pipelines` while one of the pipelines is in use.
pipelines.push(/* ... */);
// Continue pass recording.
cpass.set_bindgroup(...);

Previously, a set pipeline (or other resource) had to outlive pass recording which often affected wider systems, meaning that users needed to prove to the borrow checker that Vec<wgpu::RenderPipeline> (or similar constructs) aren't accessed mutably for the duration of pass recording.

Furthermore, you can now opt out of wgpu::RenderPass/wgpu::ComputePass's lifetime dependency on its parent wgpu::CommandEncoder using wgpu::RenderPass::forget_lifetime/wgpu::ComputePass::forget_lifetime:

fn independent_cpass<'enc>(encoder: &'enc mut wgpu::CommandEncoder) -> wgpu::ComputePass<'static> {
    let cpass: wgpu::ComputePass<'enc> = encoder.begin_compute_pass(&wgpu::ComputePassDescriptor::default());
    cpass.forget_lifetime()
</tr></table> 

... (truncated)

Commits

• 278d278 chore: remove non-existent wgpu-example workspace dep.
• e883fa7 docs(CHANGELOG): add Unreleased section
• 6a1432c chore: release 22.0.0
• 9a0adef use ManuallyDrop instead of Option for PendingWrites
• 77e45d4 add missing device valid check in create_texture_view
• f767220 remove same device check from create_texture_binding
• ed67ff2 [deno] remove assertDeviceMatch
• 63303d4 add missing same device checks
• 2f7860b move same device check in compute_pass_end_impl
• 7761b57 move same device checks in render_pass_end
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot[bot]]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.