Skip to content

Explainer: better explain the need for error scopes #1609

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.

Sign up for GitHub

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

Merged
kainino0x merged 1 commit into from
Apr 8, 2021
Merged

Explainer: better explain the need for error scopes #1609

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 11 additions & 5 deletions explainer/index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,10 +234,21 @@ that occur. To solve this, WebGPU uses *Error Scopes*.

### Error Scopes ### {#errors-errorscopes}

WebGL exposed errors using a `getError` function returning the first error the last `getError` call.
This is simple, but has two problems.

- It is synchronous, incurring a round-trip and requiring all previously issued work to be finished.
We solve this by returning errors asynchronously.
- Its flat state model composes poorly: errors can leak to/from unrelated code, possibly in
libraries/middleware, browser extensions, etc. We solve this with a stack of error "scopes",
allowing each component to hermetically capture and handle its own errors.

Each device<sup>1</sup> maintains a persistent "error scope" stack state.
Initially, the device's error scope stack is empty.
`GPUDevice.pushErrorScope('validation')` or `GPUDevice.pushErrorScope('out-of-memory')`
begins an error scope and pushes it onto the stack.
This scope captures only errors of a particular type depending on the type of error the application
wants to detect.

`GPUDevice.popErrorScope()` ends an error scope, popping it from the stack and returning a
`Promise<GPUError?>`, which resolves once all enclosed fallible operations have completed and
Expand All @@ -246,11 +257,6 @@ It resolves to `null` if no errors were captured, and otherwise resolves to an o
the first error that was captured by the scope - either a `GPUValidationError` or a
`GPUOutOfMemoryError`.

An error scope captures an error if its filter (`'validation'` or `'out-of-memory'`) matches the
type of the error.
This filter mechanism avoids, e.g., accidentally silencing validation errors when trying to
implement fallible allocation.

Any device-timeline error from an operation is passed to the top-most error scope on the stack at
the time it was issued.

Expand Down