gfx-rs/wgpu · critical
No context available. You need to enable one of wgpu's backe
Error message
No context available. You need to enable one of wgpu's backend feature build flags.
What it means
This panic comes from the `Deref` implementation of the dispatch enums generated by `dispatch_types!` (wgpu/src/dispatch.rs:902). When wgpu is compiled with NEITHER the `wgpu_core` NOR the `webgpu` feature, every match arm is cfg'd out, so dereferencing any dispatch handle (or calling any trait method on it) has no variant to return and panics with 'No context available...'. wgpu requires at least one backend feature to function.
Source
Thrown at wgpu/src/dispatch.rs:902
fn from(value: $webgpu_type) -> Self {
Self::WebGPU(value)
}
}
impl core::ops::Deref for $name {
type Target = dyn $interface;
#[inline]
fn deref(&self) -> &Self::Target {
match self {
#[cfg(wgpu_core)]
Self::Core(value) => value,
#[cfg(webgpu)]
Self::WebGPU(value) => value,
#[cfg(custom)]
Self::Custom(value) => value.deref(),
#[cfg(not(any(wgpu_core, webgpu)))]
_ => panic!("No context available. You need to enable one of wgpu's backend feature build flags."),
}
}
}
explicit_send_sync_impl!($name);
};
(
mut type $name:ident: $interface:ident = $core_type:ident,$webgpu_type:ident,$custom_type:ident
) => {
#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub enum $name {
#[cfg(wgpu_core)]
Core($core_type),
#[cfg(webgpu)]
WebGPU($webgpu_type),
#[allow(clippy::allow_attributes, private_interfaces)]
#[cfg(custom)]
Custom($custom_type),View on GitHub (pinned to 3e11ff59bf)
Solutions
- Enable a backend feature in Cargo.toml: `wgpu = { features = ["wgpu_core"] }` (or `"webgpu"` for WASM)
- If using `default-features = false`, re-enable defaults or explicitly list `wgpu_core`/`webgpu`
- Verify with `cargo tree -e features -p wgpu` or `cargo metadata` that a backend feature is active in the resolved build
- If a fully stubbed build is intended, guard all wgpu usage behind `#[cfg(any(wgpu_core, webgpu))]` so the panicking code is never compiled/called
Example fix
// before (Cargo.toml)
wgpu = { version = "24", default-features = false }
// after (Cargo.toml)
wgpu = { version = "24", default-features = false, features = ["wgpu_core"] } Defensive patterns
Strategy: validation
Validate before calling
// Cargo.toml — verify a backend feature is enabled before building
// wgpu = { features = ["wgpu_core"] }
// CI check:
// cargo metadata | jq '.packages[] | select(.name=="wgpu")' Try / catch
// Panic cannot be caught; guard at build time instead
#[cfg(not(any(feature = "wgpu_core", feature = "webgpu")))]
compile_error!("Enable the wgpu_core or webgpu feature"); Prevention
- Never use default-features = false without re-adding a backend feature
- Add a compile_error! guard for feature-less configurations
- Run `cargo tree -e features` in CI to verify backend features resolve
- Document required wgpu features in your crate's feature docs
When it happens
Trigger: Compiling the `wgpu` crate with all backend feature flags disabled (no `wgpu_core`, no `webgpu`), then constructing or using any wgpu resource (device, bind group, etc.) whose Deref hits the catch-all arm — e.g. running benches/benches/wgpu-benchmark/bind_groups.rs against a feature-less wgpu build.
Common situations: Dependending on wgpu with `default-features = false` and forgetting to add a backend feature; minimal/embedded builds trimming features; CI matrix configs that accidentally drop backend features; custom-backend setups that enable only `custom` plus cfg conditions not matching (though `custom` alone avoids this arm).
Related errors
- Earlier check of `enabled_backend_features` should have prev
- wgpu error: {err}
- Mismatched pop_error_scope call: no error scope for this thr
- Mismatched pop_error_scope call: error scopes must be popped
- ${name} is not webgpu
AI-assisted analysis of gfx-rs/wgpu@3e11ff59bf (2026-09-03).
Data as JSON: /api/errors/44e911008106c870.
Report an issue: GitHub.