Panic when I replaced the model in the example program in burn-onnx image-classification-web

[ddhello]

Hello!
I recently look into Burn, I am trying to run a image classification model on web.
I noticed that the burn-onnx repository contains an example program for image classification, so I modeled my code after that example.
The program runs very well when I use the same model of the example program(squeezenet1_opset16.onnx).
However, When I was trying to use MobileNet and ResNet, the program still runs well in NdArray, But It will panic when I use the WebGPU backend.

The panic information is:

/rustc/4a4ef493e3a1488c6e321570238084b38948f6db/library/std/src/sys/sync/condvar/no_threads.rs:20:9:
condvar wait not supported

gnu/lib/rustlib/src/rust/library/std/src/sys/sync/mutex/no_threads.rs:19:9:
assertion left == right failed: cannot recursively acquire mutex
left: true
right: false

Based on my research, I understand that WASM typically runs in a single-threaded environment. I’m curious why SqueezeNet runs smoothly without triggering these thread-related panics, while larger models like MobileNet or ResNet do. Is it possible that the increased complexity or memory demands of these models are forcing synchronous blocking or recursive mutex acquisitions within the WebGPU runtime?
Is there a known limitation for model complexity/size when running burn on WASM on wgpu?

[laggui]

Thanks for flagging this!

This is likely not due to model size. It's most likely caused by some operations that trigger a blocking synchronization (.into_data()).

I'm assuming the MobileNet and ResNet models are imported from ONNX too?

If it happens during execution: the ONNX import codegen might be introducing some sync points in some fallback cases.
If it happens during loading: burn-store might be introducing these, but not sure why.

[antimora]

Opened an issue tracel-ai/burn-onnx#325 to investigate