gfx-rs/wgpu · error
not implemented
Error message
not implemented
What it means
The SPIR-V backend of naga does not implement the `ImageClass::External` texture class (external images, e.g. VK_EXT_external_memory / GL_TEXTURE_EXTERNAL_OES style images). When write_type_declaration_arena processes a type whose inner type is an external image, request_type_capabilities hits an unimplemented!() and panics, aborting shader translation.
Source
Thrown at naga/src/back/spv/writer.rs:2017
}
}
}
fn request_type_capabilities(&mut self, inner: &crate::TypeInner) -> Result<(), Error> {
match *inner {
crate::TypeInner::Image {
dim,
arrayed,
class,
} => {
let sampled = match class {
crate::ImageClass::Sampled { .. } => true,
crate::ImageClass::Depth { .. } => true,
crate::ImageClass::Storage { format, .. } => {
self.request_image_format_capabilities(format.into())?;
false
}
crate::ImageClass::External => unimplemented!(),
};
match dim {
crate::ImageDimension::D1 => {
if sampled {
self.require_any("sampled 1D images", &[spirv::Capability::Sampled1D])?;
} else {
self.require_any("1D storage images", &[spirv::Capability::Image1D])?;
}
}
crate::ImageDimension::Cube if arrayed => {
if sampled {
self.require_any(
"sampled cube array images",
&[spirv::Capability::SampledCubeArray],
)?;
} else {
self.require_any(View on GitHub (pinned to 3e11ff59bf)
Solutions
- Replace the external image type with a standard Sampled or Storage image type in the shader/IR before SPIR-V export
- Use a backend that supports external images (e.g. the GLSL backend, or handle the texture in the app via separate bind types)
- Check naga releases/issues for external image SPIR-V support and upgrade when available
- Pre-validate the module: walk crate::Module types and reject ImageClass::External before calling the spv backend
Example fix
// before: IR contains TypeInner::Image { class: ImageClass::External, .. }
// after: rewrite to a sampled image
// let inner = TypeInner::Image { dim, arrayed, class: crate::ImageClass::Sampled { kind: ScalarKind::Float, multi: false } }; Defensive patterns
Strategy: validation
Validate before calling
fn uses_external_image(module: &naga::Module) -> bool {
module.types.iter().any(|(_, t)| matches!(t.inner, naga::TypeInner::Image { class: naga::ImageClass::External, .. }))
}
// if uses_external_image(&module) { fall back to another backend or rewrite the type } Type guard
fn is_external_image(inner: &naga::TypeInner) -> bool {
matches!(inner, naga::TypeInner::Image { class: naga::ImageClass::External, .. })
} Try / catch
// naga returns Result for translation; the panic here aborts the process, so pre-validate instead of catching
let result = naga::back::spv::write_vec(&module, &header, &options, &pipeline);
match result { Ok(spv) => ..., Err(e) => eprintln!("spv export failed: {e}") } Prevention
- Pre-scan naga IR for ImageClass::External before SPIR-V export
- Keep external textures out of shaders targeted at SPIR-V
- Pin to naga versions matching your IR feature set and read backend limitation docs
When it happens
Trigger: Compiling a WGSL/GLSL/SPIR-V shader that declares a texture whose naga IR type has ImageClass::External, then translating it to SPIR-V via naga's spv backend.
Common situations: Frontends producing naga IR with external image types (e.g. Android/HAL camera or video surface textures, GL external textures) being fed into the SPIR-V writer; naga's SPIR-V export path simply lacks support for this feature.
Related errors
- not implemented
- Unexpected saturate({:?})
- Unexpected sign({:?})
- Unexpected firstLeadingBit({:?})
- Unexpected pointer expression {:?}
AI-assisted analysis of gfx-rs/wgpu@3e11ff59bf (2026-09-03).
Data as JSON: /api/errors/a64f02e5ab4a0655.
Report an issue: GitHub.