-
|
We're facing a peculiar and annoying issue, and I'm not sure whether it is a bug or a misuse of the API. #[cfg_attr(not(target_arch = "wasm32"), tokio::test)]
#[cfg_attr(target_arch = "wasm32", wasm_bindgen_test::wasm_bindgen_test)]
async fn some_test() {
let (device, queue) = wgpu::Instance::default_device_and_queue().await;
// test logic continues, but crash happens above. See implementation of `default_device_and_queue` following
}
pub(crate) trait InstanceUtils {
async fn default_device_and_queue() -> (wgpu::Device, wgpu::Queue);
}
impl InstanceUtils for wgpu::Instance {
async fn default_device_and_queue() -> (wgpu::Device, wgpu::Queue) {
let instance = wgpu::Instance::new(wgpu::InstanceDescriptor {
backends: wgpu::Backends::all(),
flags: wgpu::InstanceFlags::empty(),
dx12_shader_compiler: wgpu::Dx12Compiler::default(),
gles_minor_version: wgpu::Gles3MinorVersion::Automatic,
});
// On WASM a surface must be created from the same instance, and must be kept alive until
// after the call to `request_adapter`. This means we cannot ignore the return value
// (otherwise it is immediately dropped), and we cannot put the entire thing in braces
// (otherwise it will be dropped at the end of the block, before creating the adapter).
#[cfg(target_arch = "wasm32")]
let _s = instance
.create_surface_from_offscreen_canvas(web_sys::OffscreenCanvas::new(1, 1).unwrap())
.unwrap();
let adapter = instance // <====== Crash happens here.
.request_adapter(&wgpu::RequestAdapterOptions {
power_preference: wgpu::PowerPreference::HighPerformance,
force_fallback_adapter: false,
compatible_surface: None,
})
.await
.expect("Failed to create wgpu::Adapter");
// Make sure the surface is dropped only after the adapter is created.
#[cfg(target_arch = "wasm32")]
drop(_s);
adapter
.request_device(
&wgpu::DeviceDescriptor {
label: Some("Default Test Device"),
features: wgpu::Features::empty(),
limits: wgpu::Limits::downlevel_webgl2_defaults(),
},
None,
)
.await
.expect("Failed to create wgpu::Device")
}
}The output we get is: Line 11 in the stack trace refers to the call to All test methods start with the same call to I saw #5086 which lists a similar issue, but there it seems the issue is constant, whereas in my case it is intermittent. |
Beta Was this translation helpful? Give feedback.
Answered by
ashdnazg
Mar 5, 2024
Replies: 1 comment
Answer selected by
ltxitai
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Opened issue here: #5349 and PR here: #5351