fix(deps): update rust crate wgpu to v24 #155
Open
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.
This PR contains the following updates:
0.20
->24.0
Release Notes
gfx-rs/wgpu (wgpu)
v24.0.0
Compare Source
Major changes
Refactored Dispatch Between
wgpu-core
andwebgpu
The crate
wgpu
has two different "backends", one which targets webgpu in the browser, one which targetswgpu_core
on native platforms and webgl. This was previously very difficult to traverse and add new features to. The entire system was refactored to make it simpler. Additionally the new system has zero overhead if there is only one "backend" in use. You can see the new system in action by using go-to-definition on any wgpu functions in your IDE.By @cwfitzgerald in #6619.
Render and Compute Passes Now Properly Enforce Their Lifetime
A regression introduced in 23.0.0 caused lifetimes of render and compute passes to be incorrectly enforced. While this is not
a soundness issue, the intent is to move an error from runtime to compile time. This issue has been fixed and restored to the 22.0.0 behavior.
Bindless (
binding_array
) Grew More CapabilitiesPARTIALLY_BOUND_BINDING_ARRAY
on Resource Binding Tier 3 Hardware. This is most D3D12 hardware D3D12 Feature Table for more information on what hardware supports this feature. By @cwfitzgerald in #6734.Device::create_shader_module_unchecked
Renamed and Now Has Configuration Optionscreate_shader_module_unchecked
becamecreate_shader_module_trusted
.This allows you to customize which exact checks are omitted so that you can get the correct balance of performance and safety for your use case. Calling the function is still unsafe, but now can be used to skip certain checks only on certain builds.
This also allows users to disable the workarounds in the
msl-out
backend to prevent the compiler from optimizing infinite loops. This can have a big impact on performance, but is not recommended for untrusted shaders.By @cwfitzgerald and @rudderbucky in #6662.
wgpu::Instance::new
now takesInstanceDescriptor
by referencePreviously
wgpu::Instance::new
tookInstanceDescriptor
by value (which is overall fairly uncommon in wgpu).Furthermore,
InstanceDescriptor
is now cloneable.By @wumpf in #6849.
Environment Variable Handling Overhaul
Previously how various bits of code handled reading settings from environment variables was inconsistent and unideomatic.
We have unified it to (
Type::from_env()
orType::from_env_or_default()
) andType::with_env
for all types.By @cwfitzgerald in #6895
Backend-specific instance options are now in separate structs
In order to better facilitate growing more interesting backend options, we have put them into individual structs. This allows users to more easily understand what options can be defaulted and which they care about. All of these new structs implement
from_env()
and delegate to their respectivefrom_env()
methods.If you do not need any of these options, or only need one backend's info use the
default()
impl to fill out the remaining feelds.By @cwfitzgerald in #6895
The
diagnostic(…);
directive is now supported in WGSLNaga now parses
diagnostic(…);
directives according to the WGSL spec. This allows users to control certain lints, similar to Rust'sallow
,warn
, anddeny
attributes. For example, in standard WGSL (but, notably, not Naga yet—see #4369) this snippet would emit a uniformity error:…but we can now silence it with the
off
severity level, like so:There are some limitations to keep in mind with this new functionality:
@diagnostic(…)
rules asfn
attributes, but prioritization for rules in statement positions (i.e.,if (…) @​diagnostic(…) { … }
is unclear. If you are blocked by not being able to parsediagnostic(…)
rules in statement positions, please let us know in #5320, so we can determine how to prioritize it!error
,warning
,info
, andoff
severity levels. These are all technically usable now! A caveat, though: warning- and info-level are only emitted tostderr
via thelog
façade, rather than being reported through aResult::Err
in Naga or theCompilationInfo
interface inwgpu{,-core}
. This will require breaking changes in Naga to fix, and is being tracked by #6458.diagnostic(…)
rules. In fact, only thederivative_uniformity
triggering rule exists in the WGSL standard. That said, Naga contributors are excited to see how this level of control unlocks a new ecosystem of configurable diagnostics.diagnostic(…)
rules are not yet emitted in WGSL output. This means thatwgsl-in
→wgsl-out
is currently a lossy process. We felt that it was important to unblock users who neededdiagnostic(…)
rules (i.e., #3135) before we took significant effort to fix this (tracked in #6496).By @ErichDonGubler in #6456, #6148, #6533, #6353, #6537.
New Features
Naga
naga
CLI would incorrectly skip the first positional argument when--stdin-file-path
was specified. By @ErichDonGubler in #6480.quantizeToF16()
for WGSL frontend, and WGSL, SPIR-V, HLSL, MSL, and GLSL backends. By @jamienicol in #6519.usampler*
andisampler*
. By @DavidPeicho in #6513.{U,S}{int,norm}{8,16}
,Float16
andUnorm8x4Bgra
). By @nolanderc in #6632workgroup_size
. By @KentSlaney in #6635.General
map_async
andon_submitted_work_done
to track down completion of async callbacks. By @eliemichel in #6360..dll
files. By @DouglasDwyer in #6574.DeviceType
andAdapterInfo
now implHash
by @cwfitzgerald in #6868wgsl_language_features
for obtaining available WGSL language feature by @sagudev in #6814no_std
support towgpu-types
. By @bushrat011899 in #6892.Vulkan
VK_EXT_shader_atomic_float
. By @AsherJingkongChen in #6234.Metal
raw_handle
method to access raw Metal textures in #6894.D3D12
Changes
Naga
override
initializers. By @sagudev in 6920General
Surface::as_hal
take an immutable reference to the surface. By @jerzywilczek in #9999CreateBindGroupError::InvalidTextureSampleType
error message. By @ErichDonGubler in #6530.Surface::configure
andSurface::get_current_texture
are no longer fatal. By @alokedesai in #6253BlasTriangleGeometry::index_buffer_offset
toBlasTriangleGeometry::first_index
. By @Vecvec in #6873D3D12
dxcompiler.dll
&dxil.dll
are also now required. By @teoxoy in #6643.Vulkan
HAL
usage: Range<T>
, forBufferUses
,TextureUses
, andAccelerationStructureBarrier
with a newStateTransition<T>
. By @atlv24 in #6703DropCallback
API to useFnOnce
instead ofFnMut
. By @jerzywilczek in #6482Bug Fixes
General
Device
, rather than panicking. By @ErichDonGubler in #6505.Features::TIMESTAMP_QUERY
is set when using timestamp writes in render and compute passes. By @ErichDonGubler in #6497.QUERY_SET_MAX_QUERIES
(and enforced limits) from 8192 to 4096 to match WebGPU spec. By @ErichDonGubler in #6525.PreHashedMap
withFastHashMap
. By @jamienicol in #6541.TIMESTAMP_QUERY
feature before other validation.Device
on some environments. By @Dinnerbone in #6681.get_acceleration_structure_build_sizes
. By @Vecvec in #6802.wgpu-info
not showing dx12 adapters. By @wumpf in #6844.transform_buffer_offset
when initialisingtransform_buffer
. By @Vecvec in #6864.Naga
vecN
constructors have less than N arguments. By @ErichDonGubler in #6508.>=
ina<b>=c
. By @KentSlaney in #6898.Statement::ImageStore
. By @jimblandy in #6729.Vulkan
max_color_attachment_bytes_per_sample
is now correctly set to 128. By @cwfitzgerald in #6866D3D12
max_color_attachment_bytes_per_sample
is now correctly set to 128. By @cwfitzgerald in #6866Examples
Testing
v23.0.1
Compare Source
This release includes patches for
wgpu
,wgpu-core
andwgpu-hal
. All other crates remain at 23.0.0.Below changes were cherry-picked from 24.0.0 development line.
Bug fixes
General
Metal
Vulkan
v23.0.0
Compare Source
Themes of this release
This release's theme is one that is likely to repeat for a few releases: convergence with the WebGPU specification! WGPU's design and base functionality are actually determined by two specifications: one for WebGPU, and one for the WebGPU Shading Language.
This may not sound exciting, but let us convince you otherwise! All major web browsers have committed to offering WebGPU in their environment. Even JS runtimes like Node and Deno have communities that are very interested in providing WebGPU! WebGPU is slowly eating the world, as it were. 😀 It's really important, then, that WebGPU implementations behave in ways that one would expect across all platforms. For example, if Firefox's WebGPU implementation were to break when running scripts and shaders that worked just fine in Chrome, that would mean sad users for both application authors and browser authors.
WGPU also benefits from standard, portable behavior in the same way as web browsers. Because of this behavior, it's generally fairly easy to port over usage of WebGPU in JavaScript to WGPU. It is also what lets WGPU go full circle: WGPU can be an implementation of WebGPU on native targets, but also it can use other implementations of WebGPU as a backend in JavaScript when compiled to WASM. Therefore, the same dynamic applies: if WGPU's own behavior were significantly different, then WGPU and end users would be sad, sad humans as soon as they discover places where their nice apps are breaking, right?
The answer is: yes, we do have sad, sad humans that really want their WGPU code to work everywhere. As Firefox and others use WGPU to implement WebGPU, the above example of Firefox diverging from standard is, unfortunately, today's reality. It mostly behaves the same as a standards-compliant WebGPU, but it still doesn't in many important ways. Of particular note is Naga, its implementation of the WebGPU Shader Language. Shaders are pretty much a black-and-white point of failure in GPU programming; if they don't compile, then you can't use the rest of the API! And yet, it's extremely easy to run into a case like that from #4400:
We intend to continue making visible strides in converging with specifications for WebGPU and WGSL, as this release has. This is, unfortunately, one of the major reasons that WGPU has no plans to work hard at keeping a SemVer-stable interface for the foreseeable future; we have an entire platform of GPU programming functionality we have to catch up with, and SemVer stability is unfortunately in tension with that. So, for now, you're going to keep seeing major releases and breaking changes. Where possible, we'll try to make that painless, but compromises to do so don't always make sense with our limited resources.
This is also the last planned major version release of 2024; the next milestone is set for January 1st, 2025, according to our regular 12-week cadence (offset from the originally planned date of 2024-10-09 for this release 😅). We'll see you next year!
Contributor spotlight: @sagudev
This release, we'd like to spotlight the work of @sagudev, who has made significant contributions to the WGPU ecosystem this release. Among other things, they contributed a particularly notable feature where runtime-known indices are finally allowed for use with
const
array values. For example, this WGSL shader previously wasn't allowed:…but now it works! This is significant because this sort of shader rejection was one of the most impactful issues we are aware of for converging with the WGSL specification. There are more still to go—some of which we expect to even more drastically change how folks author shaders—but we suspect that many more will come in the next few releases, including with @sagudev's help.
We're excited for more of @sagudev's contributions via the Servo community. Oh, did we forget to mention that these contributions were motivated by their work on Servo? That's right, a third well-known JavaScript runtime is now using WGPU to implement its WebGPU implementation. We're excited to support Servo to becoming another fully fledged browsing environment this way.
Major Changes
In addition to the above spotlight, we have the following particularly interesting items to call out for this release:
wgpu-core
is no longer generic overwgpu-hal
backendsDynamic dispatch between different backends has been moved from the user facing
wgpu
crate, to a new dynamic dispatch mechanism inside the backend abstraction layerwgpu-hal
.Whenever targeting more than a single backend (default on Windows & Linux) this leads to faster compile times and smaller binaries! This also solves a long standing issue with
cargo doc
failing to run forwgpu-core
.Benchmarking indicated that compute pass recording is slower as a consequence, whereas on render passes speed improvements have been observed. However, this effort simplifies many of the internals of the wgpu family of crates which we're hoping to build performance improvements upon in the future.
By @wumpf in #6069, #6099, #6100.
wgpu
's resources no longer have.global_id()
getterswgpu-core
's internals no longer use nor need IDs and we are moving towards removing IDs completely. This is a step in that direction.Current users of
.global_id()
are encouraged to make use of thePartialEq
,Eq
,Hash
,PartialOrd
andOrd
traits that have now been implemented forwgpu
resources.By @teoxoy in #6134.
set_bind_group
now takes anOption
for the bind group argument.https://gpuweb.github.io/gpuweb/#programmable-passes-bind-groups specifies that bindGroup is nullable. This change is the start of implementing this part of the spec. Callers that specify a
Some()
value should have unchanged behavior. Handling ofNone
values still needs to be implemented by backends.For convenience, the
set_bind_group
on compute/render passes & encoders takesimpl Into<Option<&BindGroup>>
, so most code should still work the same.By @bradwerth in #6216.
entry_point
s are nowOption
alOne of the changes in the WebGPU spec. (from about this time last year 😅) was to allow optional entry points in
GPUProgrammableStage
. Inwgpu
, this corresponds to a subset of fields inFragmentState
,VertexState
, andComputeState
as theentry_point
member:When set to
None
, it's assumed that the shader only has a single entry point associated with the pipeline stage (i.e.,@compute
,@fragment
, or@vertex
). If there is not one and only one candidate entry point, then a validation error is returned. To continue the example, we might have written the above API usage with the following shader module:WGPU's DX12 backend is now based on the
windows
crate ecosystem, instead of thed3d12
crateWGPU has retired the
d3d12
crate (based onwinapi
), and now uses thewindows
crate for interfacing with Windows. For many, this may not be a change that affects day-to-day work. However, for users who need to vet their dependencies, or who may vendor in dependencies, this may be a nontrivial migration.By @MarijnS95 in #6006.
New Features
Wgpu
Naga
firstLeadingBit
andfirstTrailingBit
numeric built-ins in WGSL. Front-ends that translate to these built-ins also benefit from constant evaluation. By @ErichDonGubler in #5101.first
andeither
sampling types for@interpolate(flat, …)
in WGSL. By @ErichDonGubler in #6181.const
declarations in WGSL. By @sagudev in #6156.const_assert
in WGSL. By @sagudev in #6198.inverse
in WGSL. By @chyyran in #6385.requires
,enable
, anddiagnostic
directives. No extensions or diagnostic filters are yet supported, but diagnostics have improved dramatically. By @ErichDonGubler in #6352, #6424, #6437.General
VideoFrame
toExternalImageSource
enum. By @jprochazk in #6170.wgpu::util::new_instance_with_webgpu_detection
&wgpu::util::is_browser_webgpu_supported
to make it easier to support WebGPU & WebGL in the same binary. By @wumpf in #6371.Vulkan
VULKAN_GOOGLE_DISPLAY_TIMING
feature. By @DJMcNab in #6149.Metal
atomicCompareExchangeWeak
. By @AsherJingkongChen in #6265.CAMetalLayer
is provided, surfaces now render to a sublayer. This improves resizing behavior, fixing glitches during on window resize. By @madsmtm in #6107.Bug Fixes
Naga
vec3
(notvecN
) for thecross
built-in. By @ErichDonGubler in #6171.SourceLanguage
when enabling debug info in SPV-out. By @kvark in #6256.var
s without explicit type. By @sagudev in #6199.gl_DrawID
to glsl andDrawIndex
to spv. By @ChosenName in #6325.textureQueryLevels
to the GLSL parser. By @magcius in #6325.General
d3d12
/naga
/wgpu-core
/wgpu-hal
/wgpu-types
' to 1.76. By @wumpf in #6003.UnsupportedUsage
error. By @VladasZ in #6007.wgpu_hal
bounds-checking promises, and adaptwgpu_core
's lazy initialization logic to the slightly weaker-than-expected guarantees. By @jimblandy in #6201.{Render,Compute}Pipeline::get_bind_group_layout
on native / WebGL. By @bgr360 in #6280.wgpu_core::render::bundle::bundle_ffi
, to allow multiple versions of WGPU to compile together. By @ErichDonGubler in #6272.flush_mapped_ranges
when unmapping write-mapped buffers. By @teoxoy in #6089.MAP_WRITE
usage. By @teoxoy in #6178.TextureFormat
andStorageFormat
. By @caelunshun in #6185GLES / OpenGL
slice::from_raw_parts
with unaligned pointers in push constant handling. By @Imberflur in #6341.Queue::submit
is called many times per frame. By @dinnerbone in #6427.WebGPU
TypeError
exception inInstance::request_adapter
when browser doesn't support WebGPU butwgpu
not compiled withwebgl
support. By @bgr360 in #6197.Vulkan
.index_type(vk::IndexType::NONE_KHR)
when creatingAccelerationStructureGeometryTrianglesDataKHR
in the raytraced triangle example to prevent a validation error. By @Vecvec in #6282.Changes
wgpu_hal::gles::Adapter::new_external
now requires the context to be current when dropping the adapter and related objects. By @Imberflur in #6114.Rg11b10Float
toRg11b10Ufloat
. By @sagudev in #6108.impl From<StorageFormat> for ScalarKind
withimpl From<StorageFormat> for Scalar
so that byte width is included. By @atlv24 in #6451.Internal
ManuallyDrop
in remaining places. By @teoxoy in #6092.Registry
. By @teoxoy in #6243.backend
from ID. By @teoxoy in #6263.HAL
DropGuard
based API on Vulkan and GLES to a consistent, callback-based one. By @jerzywilczek in #6164.Documentation
wgpu-types
documentation. Fixed Storage texel types in examples. By @Nelarius in #6271.wgpu::include_wgsl!(…)
more in examples and tests. By @ErichDonGubler in #6326.Dependency Updates
GLES
winapi
code in WGL wrapper to use thewindows
crate. By @MarijnS95 in #6006.glutin
to0.31
withglutin-winit
crate. By @MarijnS95 in #6150 and #6176.Adapter::new_external()
for WGL (just like EGL) to import an external OpenGL ES context. By @MarijnS95 in #6152.DX12
winapi
code to use thewindows
crate. By @MarijnS95 in #5956 and #6173.num_workgroups
builtin working for indirect dispatches. By @teoxoy in #5730.HAL
parking_lot
to0.12
. By @mahkoh in #6287.v22.1.0
Compare Source
This release includes
wgpu
,wgpu-core
andnaga
. All other crates remain at 22.0.0.Added
Naga
Bug Fixes
General
tracy
. By @waywardmonkeys in #5988queue_write_texture
. By @teoxoy in #6009compute_pass
. By @matthew-wong1 #6041wgpu-core
is undocumented unless--cfg wgpu_core_doc
feature is enabled. By @kpreid in #5987v22.0.0
Compare Source
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):
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:
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 parentwgpu::CommandEncoder
usingwgpu::RenderPass::forget_lifetime
/wgpu::ComputePass::forget_lifetime
:wgpu::RenderPass
/wgpu::ComputePass
is pending for a givenwgpu::CommandEncoder
, creation of a compute or render pass is an error and invalidates thewgpu::CommandEncoder
.forget_lifetime
can be very useful for library authors, but opens up an easy way for incorrect use, so use with care.This method doesn't add any additional overhead and has no side effects on pass recording.
By @wumpf in #5569, #5575, #5620, #5768 (together with @kpreid), #5671, #5794, #5884.
Querying shader compilation errors
Wgpu now supports querying shader compilation info.
This allows you to get more structured information about compilation errors, warnings and info:
By @stefnotch in #5410
64 bit integer atomic support in shaders.
Add support for 64 bit integer atomic operations in shaders.
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.