Error scopes should be handled in device timeline (wgpu thread)
Opened this issue · 2 comments
Currently they are handled in script thread, which causes problems on some tests now that we have parallel poller. In tests webgpu:shader,execution,expression,constructor,* we get very flaky results (sometimes passing test, although we shouldn't), because in attemptEndTestScope when popping validation error scope, promise does not get resolved to error (we have yet to handle validation error in handle_msg_from_webgpu_server).
SPEC: https://www.w3.org/TR/webgpu/#dom-gpudevice-poperrorscope
Given that all gpu errors are sent to script thread, we could just send poperrorscope to script thread to so it gets picked up from handle_msg_from_webgpu_server after all validation errors that needed to be in that scope are handled, but then we would be sending to same thread (I think) and we do not want that.
So if we move most error scopes handling to wgpu thread, we use ordering of messages to ensure error scopes contain all their messages. I think this way we can also reduce amount of messages send back to script thread (although https://www.w3.org/TR/webgpu/#gpuuncapturederrorevent still exists). This would also align us with specs.
Unresolved questions:
- callbacks returning gpu errors?
- validation errors from script thread (we can always just add new msg for it, but are they even needed as all validation should (but currently does not) happen in wgpu-core)
validation errors from script thread (we can always just add new msg for it, but are they even needed as all validation should (but currently does not) happen in wgpu-core)
Validation errors should indeed be raised from wgpu-core, but JS errors (Operation, TypeError) are actually in our domain, so not all validation can be moved to wgpu-core ...