-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reporting DeviceLost in various functions and callbacks #209
Labels
async
Asynchronous operations and callbacks
errors
Error reporting
has resolution
Issue is resolved, just needs to be done
Comments
kainino0x
added
async
Asynchronous operations and callbacks
!discuss
Needs discussion (at meeting or online)
errors
Error reporting
labels
Aug 3, 2023
We should probably match the JS API and pretend things worked. |
|
kainino0x
added
has resolution
Issue is resolved, just needs to be done
and removed
!discuss
Needs discussion (at meeting or online)
labels
Aug 24, 2023
This changes to |
kainino0x
added a commit
to kainino0x/webgpu-headers
that referenced
this issue
Nov 9, 2024
We didn't discuss which status we would use for this but "Lost" makes sense. Issue webgpu-native#209
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
async
Asynchronous operations and callbacks
errors
Error reporting
has resolution
Issue is resolved, just needs to be done
Currently we report DeviceLost in the following places aside from just the DeviceLost callback - places where the JS API does not report it:
The JS API specifies generally that async operations pretend to work successfully after the device is lost (except for MapAsync): gpuweb/gpuweb#1629 (comment)
Should we keep these DeviceLost enum values or should we do more like what the JS API does and pretend everything worked? Notably WASM can only do what JS does, so this makes it a native-only return value - but so are many of the others.
The text was updated successfully, but these errors were encountered: