v23.1.0 (2024-12-16)

This release only contains naga v23.1.0 all other packages are still at their previous versions.

New Features

Naga

• Expose Ray Query flags as constants in WGSL. Implement candidate intersections. By @kvark in #5429

23.0.1 (2024-11-25)

This release includes patches for wgpu, wgpu-core and wgpu-hal. All other crates remain at 23.0.0.
Below changes were cherry-picked from 24.0.0 development line.

Bug fixes

General

• Fix Texture view leaks regression. By @xiaopengli89 in #6576

Metal

• Fix surface creation crashing on iOS. By @mockersf in #6535

Vulkan

• Fix surface capabilities being advertised when its query failed. By @Wumpf in #6510

v23.0.0 (2024-10-25)

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:

fn gimme_a_float() -> f32 {
  return 42; // fails in Naga, but standard WGSL happily converts to `f32`
}

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:

const arr: array<u32, 4> = array(1, 2, 3, 4);

fn what_number_should_i_use(idx: u32) -> u32 {
  return arr[idx];
}

…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 over wgpu-hal backends

Dynamic dispatch between different backends has been moved from the user facing wgpu crate, to a new dynamic dispatch mechanism inside the backend abstraction layer wgpu-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 for wgpu-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() getters

wgpu-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 the PartialEq, Eq, Hash, PartialOrd and Ord traits that have now been implemented for wgpu resources.

By @teoxoy in #6134.

set_bind_group now takes an Option 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 of None values still needs to be implemented by backends.

For convenience, the set_bind_group on compute/render passes & encoders takes impl Into<Option<&BindGroup>>, so most code should still work the same.

By @bradwerth in #6216.

entry_points are now Optional

One of the changes in the WebGPU spec. (from about this time last year 😅) was to allow optional entry points in GPUProgrammableStage. In wgpu, this corresponds to a subset of fields in FragmentState, VertexState, and ComputeState as the entry_point member:

let render_pipeline = device.createRenderPipeline(wgpu::RenderPipelineDescriptor {
    module,
    entry_point: Some("cs_main"), // This is now `Option`al.
    // …
});

let compute_pipeline = device.createComputePipeline(wgpu::ComputePipelineDescriptor {
    module,
    entry_point: None, // This is now `Option`al.
    // …
});

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:

// We can't use `entry_point: None` for compute pipelines with this module,
// because there are two `@compute` entry points.

@compute
fn cs_main() { /* … */ }

@compute
fn other_cs_main() { /* … */ }

// The following entry points _can_ be inferred from `entry_point: None` in a
// render pipeline, because they're the only `@vertex` and `@fragment` entry
// points:

@vertex
fn vs_main() { /* … */ }

@fragment
fn fs_main() { /* … */ }

WGPU's DX12 backend is now based on the windows crate ecosystem, instead of the d3d12 crate

WGPU has retired the d3d12 crate (based on winapi), and now uses the windows 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

Naga

• Support constant evaluation for firstLeadingBit and firstTrailingBit numeric built-ins in WGSL. Front-ends that translate to these built-ins also benefit from constant evaluation. By @ErichDonGubler in #5101.
• Add first and either sampling types for @interpolate(flat, …) in WGSL. By @ErichDonGubler in #6181.
• Support for more atomic ops in the SPIR-V frontend. By @schell in #5824.
• Support local const declarations in WGSL. By @sagudev in #6156.
• Implemented const_assert in WGSL. By @sagudev in #6198.
• Support polyfilling inverse in WGSL. By @chyyran in [#6385]...

v22.1.0

This release includes wgpu, wgpu-core and naga. All other crates remain at 22.0.0.

Added

Naga

• Added back implementations of PartialEq for more IR types. By @teoxoy in #6045

Bug Fixes

General

• Fix profiling with tracy. By @waywardmonkeys in #5988
• Fix function for checking bind compatibility to error instead of panic. By @sagudev #6012
• Fix crash when dropping the surface after the device. By @Wumpf in #6052
• Fix length of copy in queue_write_texture. By @teoxoy in #6009
• Fix error message that is thrown in create_render_pass to no longer say compute_pass. By @matthew-wong1 #6041
• As a workaround for issue #4905, wgpu-core is undocumented unless --cfg wgpu_core_doc feature is enabled. By @kpreid in #5987

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.
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:

...
let lighting_shader = ctx.device.create_shader_module(include_wgsl!("lighting.wgsl"));
let compilation_info = lighting_shader.get_compilation_info().await;
for message in compilation_info
    .messages
    .iter()
    .filter(|m| m.message_type == wgpu::CompilationMessageType::Error)
{
    let line = message.location.map(|l| l.line_number).unwrap_or(1);
    println!("Compile error at line {line}");
}

By @stefnotch in #5410

64 bit integer atomic support in shaders.

Add support for 64 bit integer atomic operations in shaders.

Add the following flags to wgpu_types::Features:

• SHADER_INT64_ATOMIC_ALL_OPS enables all atomic operations on atomic<i64> and
  atomic<u64> values.

• SHADER_INT64_ATOMIC_MIN_MAX is a subset of the above, enabling only
  AtomicFunction::Min and AtomicFunction::Max operations on atomic<i64> and
  atomic<u64> values in the Storage address space. These are the only 64-bit
  atomic operations available on Metal as of 3.1.

Add corresponding flags to naga::valid::Capabilities. These are supported by the
WGSL front end, and all Naga backends.

Platform support:

• On Direct3d 12, in D3D12_FEATURE_DATA_D3D12_OPTIONS9, if
  AtomicInt64OnTypedResourceSupported and AtomicInt64OnGroupSharedSupported are
  both available, then both wgpu features described above are available.

• On Metal, SHADER_INT64_ATOMIC_MIN_MAX is available on Apple9 hardware, and on
  hardware that advertises both Apple8 and Mac2 support. This also requires Metal
  Shading Language 2.4 or later. Metal does not yet support the more general
  SHADER_INT64_ATOMIC_ALL_OPS.

• On Vulkan, if the VK_KHR_shader_atomic_int64 extension is available with both the
  shader_buffer_int64_atomics and shader_shared_int64_atomics features, then both
  wgpu features described above are available.

By @atlv24 in #5383

A compatible surface is now required for request_adapter() on WebGL2 + enumerate_adapters() is now native only.

When targeting WebGL2, it has always been the case that a surface had to be created before calling request_adapter().
We now make this requirement explicit.

Validation was also added to prevent configuring the surface with a device that doesn't share the same underlying
WebGL2 context since this has never worked.

Calling enumerate_adapters() when targeting WebGPU used to return an empty Vec and since we now require users
to pass a compatible surface when targeting WebGL2, having enumerate_adapters() doesn't make sense.

By @teoxoy in #5901

New features

General

• Added as_hal for Buffer to access wgpu created buffers form wgpu-hal. By @JasondeWolff in #5724
• include_wgsl! is now callable in const contexts by @9SMTM6 in #5872
• Added memory allocation hints to DeviceDescriptor by @nical in #5875
  • MemoryHints::Performance, the default, favors performance over memory usage and will likely cause large amounts of VRAM to be allocated up-front. This hint is typically good for games.
  • MemoryHints::MemoryUsage favors memory usage over performance. This hint is typically useful for smaller applications or UI libraries.
  • MemoryHints::Manual allows the user to specify parameters for the underlying GPU memory allocator. These parameters are subject to change.
  • These hints may be ignored by some backends. Currently only the Vulkan and D3D12 backends take them into account.

Naga

• Added -D, --defines option to naga CLI to define preprocessor macros by @theomonnom in #5859

• Added type upgrades to SPIR-V atomic support. Added related infrastructure. Tracking issue is here. By @schell in #5775.

• Implement WGSL's unpack4xI8,unpack4xU8,pack4xI8 and pack4xU8. By @VlaDexa in #5424

• Began work adding support for atomics to the SPIR-V frontend. Tracking issue is here. By @schell in #5702.

• In hlsl-out, allow passing information about the fragment entry point to omit vertex outputs that are not in the fragment inputs. By @Imberflur in #5531

• In spv-out, allow passing acceleration_structure as a function argument. By @kvark in #5961

  let writer: naga::back::hlsl::Writer = /* ... */;
  -writer.write(&module, &module_info);
  +writer.write(&module, &module_info, None);

...

v0.20.2

This release bumps wgpu-core and wgpu-hal to 0.21.1, to resolve some undefined behavior observable in the DX12 backend after upgrading to Rust 1.79 or later. We also include a fix for a command buffer leak.

Bug Fixes

General

• Fix a CommandBuffer leak. By @cwfitzgerald and @nical in #5141

DX12

• Do not feed &"" to D3DCompile, by @workingjubilee in #5812.

Full Changelog: v0.20.1...v0.20.2

v0.20.1

This release included v0.21.0 of wgpu-core and wgpu-hal, due to breaking changes needed to solve vulkan validation issues. It also includes v0.20.1 for wgpu and wgpu-info.

Bug Fixes

This release fixes the validation errors whenever a surface is used with the vulkan backend. By @cwfitzgerald in #5681.

General

• Clean up weak references to texture views and bind groups to prevent memory leaks. By @xiaopengli89 in #5595.
• Fix segfault on exit if queue & device are dropped before surface. By @sagudev in #5640.

Metal

• Fix unrecognized selector crash on iOS 12. By @VladasZ in #5744.

Vulkan

• Fix enablement of subgroup ops extension on Vulkan devices that don't support Vulkan 1.3. By @cwfitzgerald in #5624.

GLES / OpenGL

• Fix regression on OpenGL (EGL) where non-sRGB still used sRGB #5642

v0.20.0

Major Changes

Pipeline overridable constants

Wgpu supports now pipeline-overridable constants

This allows you to define constants in wgsl like this:

override some_factor: f32 = 42.1337; // Specifies a default of 42.1337 if it's not set.

And then set them at runtime like so on your pipeline consuming this shader:

// ...
fragment: Some(wgpu::FragmentState {
    compilation_options: wgpu::PipelineCompilationOptions {
        constants: &[("some_factor".to_owned(), 0.1234)].into(), // Sets `some_factor` to 0.1234.
        ..Default::default()
    },
    // ...
}),
// ...

By @teoxoy & @jimblandy in #5500

Changed feature requirements for timestamps

Due to a specification change write_timestamp is no longer supported on WebGPU.
wgpu::CommandEncoder::write_timestamp requires now the new wgpu::Features::TIMESTAMP_QUERY_INSIDE_ENCODERS feature which is available on all native backends but not on WebGPU.

By @Wumpf in #5188

Wgsl const evaluation for many more built-ins

Many numeric built-ins have had a constant evaluation implementation added for them, which allows them to be used in a const context:

abs, acos, acosh, asin, asinh, atan, atanh, cos, cosh, round, saturate, sin, sinh, sqrt, step, tan, tanh, ceil, countLeadingZeros, countOneBits, countTrailingZeros, degrees, exp, exp2, floor, fract, fma, inverseSqrt, log, log2, max, min, radians, reverseBits, sign, trunc

By @ErichDonGubler in #4879, #5098

New native-only wgsl features

Subgroup operations

The following subgroup operations are available in wgsl now:

subgroupBallot, subgroupAll, subgroupAny, subgroupAdd, subgroupMul, subgroupMin, subgroupMax, subgroupAnd, subgroupOr, subgroupXor, subgroupExclusiveAdd, subgroupExclusiveMul, subgroupInclusiveAdd, subgroupInclusiveMul, subgroupBroadcastFirst, subgroupBroadcast, subgroupShuffle, subgroupShuffleDown, subgroupShuffleUp, subgroupShuffleXor

Availability is governed by the following feature flags:

• wgpu::Features::SUBGROUP for all operations except subgroupBarrier in fragment & compute, supported on Vulkan, DX12 and Metal.
• wgpu::Features::SUBGROUP_VERTEX, for all operations except subgroupBarrier general operations in vertex shaders, supported on Vulkan
• wgpu::Features::SUBGROUP_BARRIER, for support of the subgroupBarrier operation, supported on Vulkan & Metal

Note that there currently some differences between wgpu's native-only implementation and the open WebGPU proposal.

By @exrook and @Lichtso in #5301

Signed and unsigned 64 bit integer support in shaders.

wgpu::Features::SHADER_INT64 enables 64 bit integer signed and unsigned integer variables in wgsl (i64 and u64 respectively).
Supported on Vulkan, DX12 (requires DXC) and Metal (with MSL 2.3+ support).

By @atlv24 and @cwfitzgerald in #5154

New features

General

• Implemented the Unorm10_10_10_2 VertexFormat by @McMackety in #5477
• wgpu-types's trace and replay features have been replaced by the serde feature. By @KirmesBude in #5149
• wgpu-core's serial-pass feature has been removed. Use serde instead. By @KirmesBude in #5149
• Added InstanceFlags::GPU_BASED_VALIDATION, which enables GPU-based validation for shaders. This is currently only supported on the DX12 and Vulkan backends; other platforms ignore this flag, for now. By @ErichDonGubler in #5146, #5046.
  • When set, this flag implies InstanceFlags::VALIDATION.
  • This has been added to the set of flags set by InstanceFlags::advanced_debugging. Since the overhead is potentially very large, the flag is not enabled by default in debug builds when using InstanceFlags::from_build_config.
  • As with other instance flags, this flag can be changed in calls to InstanceFlags::with_env with the new WGPU_GPU_BASED_VALIDATION environment variable.
• wgpu::Instance can now report which wgpu::Backends are available based on the build configuration. By @Wumpf #5167

  -wgpu::Instance::any_backend_feature_enabled()
  +!wgpu::Instance::enabled_backend_features().is_empty()

• Breaking change: wgpu_core::pipeline::ProgrammableStageDescriptor is now optional. By @ErichDonGubler in #5305.
• Features::downlevel{_webgl2,}_features was made const by @MultisampledNight in #5343
• More as_hal methods and improvements by @JMS55 in #5452
  • Added wgpu::CommandEncoder::as_hal_mut
  • Added wgpu::TextureView::as_hal
  • wgpu::Texture::as_hal now returns a user-defined type to match the other as_hal functions

Naga

• Allow user to select which MSL version to use via --metal-version with Naga CLI. By @pcleavelin in #5392
• Support arrayLength for runtime-sized arrays inside binding arrays (for WGSL input and SPIR-V output). By @kvark in #5428
• Added --shader-stage and --input-kind options to naga-cli for specifying vertex/fragment/compute shaders, and frontend. by @ratmice in #5411
• Added a create_validator function to wgpu_core Device to create naga Validators. By @atlv24 #5606

WebGPU

• Implement the device_set_device_lost_callback method for ContextWebGpu. By @suti in #5438
• Add support for storage texture access modes ReadOnly and ReadWrite. By @JolifantoBambla in #5434

GLES / OpenGL

• Log an error when GLES texture format heuristics fail. By @PolyMeilex in #5266
• Cache the sample count to keep get_texture_format_features cheap. By @Dinnerbone in #5346
• Mark DEPTH32FLOAT_STENCIL8 as supported in GLES. By @Dinnerbone in #5370
• Desktop GL now also supports TEXTURE_COMPRESSION_ETC2. By @valaphee in #5568
• Don't create a program for shader-clearing if that workaround isn't required. By @Dinnerbone in #5348.
• OpenGL will now be preferred over OpenGL ES on EGL, making it consistent with WGL. By @valaphee in #5482
• Fill out driver and driver_info, with the OpenGL flavor and version, similar to Vulkan. By @valaphee in #5482

Metal

• Metal 3.0 and 3.1 detection. By @atlv24 in #5497

DX12

• Shader Model 6.1-6.7 detection. By @atlv24 in #5498

Other performance improvements

• Simplify and speed up the allocation of internal IDs. By @nical in #5229
• Use memory pooling for UsageScopes to avoid frequent large allocations. by @robtfm in #5414
• Eager release of GPU resources comes from device.trackers. By @bradwerth in #5075
• Support disabling zero-initialization of workgroup local memory in compute shaders. By @DJMcNab in #5508

Documentation

• Improved wgpu_hal documentation. By @jimblandy in #5516, #5524, #5562, #5563, #5566, #5617, #5618
• Add mention of primitive restart in the description of PrimitiveState::strip_index_format. By @cpsdqs in #5350
• Document precise behaviour of SourceLocation. By @stefnotch in #5386
• Give short example of WGSL push_constant syntax. By @waywardmonkeys in #5393
• Fix incorrect documentation of Limits::max_compute_workgroup_storage_size default value. By @atlv24 in #5601

Bug Fixes

General

• Fix serde feature not compiling for wgpu-types. By @KirmesBude in #5149
• Fix the validation of vertex and index ranges. By @nical in #5144 and #5156
• Fix panic when creating a surface while no backend is available. By @Wumpf #5166
• Correctly compute minimum buffer size ...

v0.19.4

This release includes wgpu, wgpu-core, and wgpu-hal. All other crates are unchanged.

Bug Fixes

General

• Don't depend on bind group and bind group layout entry order in backends. This caused incorrect command execution and, in some cases, crashes. By @ErichDonGubler in #5421.
• Properly clean up all write_buffer/texture temporary resources. By @robtfm in #5413.
• Fix deadlock in certain situations when mapping buffers using wgpu-profiler. By @cwfitzgerald in #5517

WebGPU

• Correctly pass through timestamp queries to WebGPU. By @cwfitzgerald in #5527.

v0.19.3

This release includes wgpu, wgpu-core, and wgpu-hal. All other crates are unchanged.

Major Changes

Vendored WebGPU Bindings from web_sys

--cfg=web_sys_unstable_apis is no longer needed in your RUSTFLAGS to compile for WebGPU!!!

While WebGPU's javascript api is stable in the browsers, the web_sys bindings for WebGPU are still improving. As such they are hidden behind the special cfg --cfg=web_sys_unstable_apis and are not available by default. Everyone who wanted to use our WebGPU backend needed to enable this cfg in their RUSTFLAGS. This was very inconvenient and made it hard to use WebGPU, especially when WebGPU is enabled by default. Additionally, the unstable APIs don't adhere to semver, so there were repeated breakages.

To combat this problem we have decided to vendor the web_sys bindings for WebGPU within the crate. Notably we are not forking the bindings, merely vendoring, so any improvements we make to the bindings will be contributed directly to upstream web_sys.

By @cwfitzgerald in #5325.

Bug Fixes

General

• Fix an issue where command encoders weren't properly freed if an error occurred during command encoding. By @ErichDonGubler in #5251.

Android

• Fix linking error when targeting android without winit. By @ashdnazg in #5326.