-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Chrome 140 rejects duplicate requestDevice() calls on GPUDevice
#28402
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
Chrome 140 rejects duplicate requestDevice() calls on GPUDevice
#28402
Conversation
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
requestDevice() calls on GPUDevice
api/GPUAdapter.json
Outdated
| "duplicate_calls_reject": { | ||
| "__compat": { | ||
| "description": "Lost `GPUDevice` returned on duplicate calls.", | ||
| "description": "Duplicate calls reject as adapter is consumed.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not totally sure about this feature, but maybe we can abstract from the specific behavior:
| "duplicate_calls_reject": { | |
| "__compat": { | |
| "description": "Lost `GPUDevice` returned on duplicate calls.", | |
| "description": "Duplicate calls reject as adapter is consumed.", | |
| "handles_duplicate_calls": { | |
| "__compat": { | |
| "description": "Rejects duplicate calls as adapter is consumed.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in latest commit.
Summary
From Chrome 140 onwards, calling
GPUAdapter.requestDevice()multiple times on the same adapter causes the returned promise to reject. This is because the adapter is consumed by the first call. See https://developer.chrome.com/blog/new-in-webgpu-140#device_requests_consume_adapter.Previously, you could call
GPUAdapter.requestDevice()multiple times on the same adapter, but multiple calls would result in lost devices.This PR tries to capture the old and new behavior in a single data point, rather than adding multiple data points for a behavior change, which would be rather odd. Let me know if you think this works, or if we should do it a different way.
Test results and supporting details
Related issues