Open Maximetinu opened 6 months ago
generally wgpu panics in a lot of cases today where it shouldn't and instead call into the error handlers. Some of it is hard to address but others easier so it really depends on the panic you're getting.
For the quoted error I'm a bit surprised though - I trust you installed error handlers?
Actually, now that I think of it we don't "opt into panic" on WebGPU and just let the implementation (chrome in this case) decide what happens then. Whereas on everything wgpu-core (native + webgl) we panic on errors unless an error handler is installed.
This has been around for very long now. Doubting this is a good default 🤔
For the quoted error I'm a bit surprised though - I trust you installed error handlers?
In my real app, yes I did, and I'm only logging the uncaptured errors as warnings instead of panics. It prevented most of the crashes for this reason. However, minority of them still panic because of some unwrap inside of glow
In the videos I'm posting above, I'm running the wgpu examples and they panic, do they have error handlers installed? I will try to install them, and check if that prevent the panic when GPU crashes.
Hi !
I am experiencing inconsistent behavior between
WebGL2
andWebGPU
in the event of a GPU crash, and I'm unsure if it's expectedWhen a GPU crash occurs on wasm, wgpu apps using
WebGPU
keep working as usual, just without graphics, and the console logs a warning like⚠️ GPU connection lost
However, wgpu apps using
WebGL2
panic, usually by anError in Queue::submit: Validation Error. Caused by: Not enough memory left
(the actual panic depends on the reason they lost access to the GPU I presume.Repro steps
WebGL2
andWebGPU
chrome://gpucrash
in the address bar (see debug section atchrome://about/
for reference)I recorded a couple of videos showcasing this behaviour in the "Shadow" example of the repo, running on wasm with the command from the readme
cargo xtask run-wasm --bin wgpu-examples ...
Describe the solution you'd like So, in other web game engines using
webgl2
rendering, like Babylon.js, they can keep working without graphics after a fatal error like this happens, and they can even recover from it. That means that, if such web game engines were usingwgpu
andwebgpu
, they would not have to implement this by themselves, which is great.In the case of Babylon.js:
this is where they got this feature request:
and this is the PR that implemented it:
So, my question is:
Can
wgpu
implement a similar resilience forWebGL2
as well, or is this behaviour an inherent limitation of lower level actors likeglow
orWebGL2
itself?If the latter, feel free to close the issue as won't do. Thx! 😄