Bump wgpu from 0.16.2 to 0.17.0

[dependabot]

Bumps wgpu from 0.16.2 to 0.17.0.

Release notes

Sourced from wgpu's releases.

v0.17.0

This is the first release that featured wgpu-info as a binary crate for getting information about what devices wgpu sees in your system. It can dump the information in both human readable format and json.

Major Changes

This release was fairly minor as breaking changes go.

wgpu types now !Send !Sync on wasm

Up until this point, wgpu has made the assumption that threads do not exist on wasm. With the rise of libraries like wasm_thread making it easier and easier to do wasm multithreading this assumption is no longer sound. As all wgpu objects contain references into the JS heap, they cannot leave the thread they started on.

As we understand that this change might be very inconvenient for users who don't care about wasm threading, there is a crate feature which re-enables the old behavior: fragile-send-sync-non-atomic-wasm. So long as you don't compile your code with -Ctarget-feature=+atomics, Send and Sync will be implemented again on wgpu types on wasm. As the name implies, especially for libraries, this is very fragile, as you don't know if a user will want to compile with atomics (and therefore threads) or not.

By @​daxpedda in #3691

Power Preference is now optional

The power_preference field of RequestAdapterOptions is now optional. If it is PowerPreference::None, we will choose the first available adapter, preferring GPU adapters over CPU adapters.

By @​Aaron1011 in #3903

initialize_adapter_from_env argument changes

Removed the backend_bits parameter from initialize_adapter_from_env and initialize_adapter_from_env_or_default. If you want to limit the backends used by this function, only enable the watned backends in the instance.

Added a compatible surface parameter, to ensure the given device is able to be presented onto the given surface.

- wgpu::util::initialize_adapter_from_env(instance, backend_bits);
+ wgpu::util::initialize_adapter_from_env(instance, Some(&compatible_surface));

By @​fornwall in #3904 and #3905

Misc Breaking Changes

• Change AdapterInfo::{device,vendor} to be u32 instead of usize. By @​ameknite in #3760

Changes

• Added support for importing external buffers using buffer_from_raw (Dx12, Metal, Vulkan) and create_buffer_from_hal. By @​AdrianEddy in #3355

Vulkan

• Work around Vulkan-ValidationLayers#5671 by ignoring reports of violations of VUID-vkCmdEndDebugUtilsLabelEXT-commandBuffer-01912. By @​jimblandy in #3809.

Added/New Features

• Empty scissor rects are allowed now, matching the specification. by @​PJB3005 in #3863.

... (truncated)

Changelog

Sourced from wgpu's changelog.

v0.17.0 (2023-07-20)

This is the first release that featured wgpu-info as a binary crate for getting information about what devices wgpu sees in your system. It can dump the information in both human readable format and json.

Major Changes

This release was fairly minor as breaking changes go.

wgpu types now !Send !Sync on wasm

Up until this point, wgpu has made the assumption that threads do not exist on wasm. With the rise of libraries like wasm_thread making it easier and easier to do wasm multithreading this assumption is no longer sound. As all wgpu objects contain references into the JS heap, they cannot leave the thread they started on.

As we understand that this change might be very inconvenient for users who don't care about wasm threading, there is a crate feature which re-enables the old behavior: fragile-send-sync-non-atomic-wasm. So long as you don't compile your code with -Ctarget-feature=+atomics, Send and Sync will be implemented again on wgpu types on wasm. As the name implies, especially for libraries, this is very fragile, as you don't know if a user will want to compile with atomics (and therefore threads) or not.

By @​daxpedda in #3691

Power Preference is now optional

The power_preference field of RequestAdapterOptions is now optional. If it is PowerPreference::None, we will choose the first available adapter, preferring GPU adapters over CPU adapters.

By @​Aaron1011 in #3903

initialize_adapter_from_env argument changes

Removed the backend_bits parameter from initialize_adapter_from_env and initialize_adapter_from_env_or_default. If you want to limit the backends used by this function, only enable the wanted backends in the instance.

Added a compatible surface parameter, to ensure the given device is able to be presented onto the given surface.

- wgpu::util::initialize_adapter_from_env(instance, backend_bits);
+ wgpu::util::initialize_adapter_from_env(instance, Some(&compatible_surface));

By @​fornwall in #3904 and #3905

Misc Breaking Changes

• Change AdapterInfo::{device,vendor} to be u32 instead of usize. By @​ameknite in #3760

Changes

• Added support for importing external buffers using buffer_from_raw (Dx12, Metal, Vulkan) and create_buffer_from_hal. By @​AdrianEddy in #3355

Vulkan

• Work around Vulkan-ValidationLayers#5671 by ignoring reports of violations of VUID-vkCmdEndDebugUtilsLabelEXT-commandBuffer-01912. By @​jimblandy in #3809.

Added/New Features

... (truncated)

Commits

• 21098cd Add note about wgpu-info to changelog
• 493ff2e Bump wgpu versions
• bdb98b1 Chaneglog update
• 14892f0 Bump num-traits from 0.2.15 to 0.2.16 (#3955)
• 4ab9dbe Update max_bindings_per_bind_group from 640 to 1000 to reflect spec (#3942)
• f138123 Update dependencies (#3952)
• bd159ed Fix mipmap example with queries (#3951)
• cffee85 Bump core-graphics-types from 0.1.1 to 0.1.2 (#3948)
• 95cfd83 Bump smallvec from 1.10.0 to 1.11.0 (#3946)
• 1eb8497 Bump anyhow from 1.0.71 to 1.0.72 (#3949)
• 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 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]

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.