wgpu
wgpu copied to clipboard
Mechanism to trigger device loss and other errors, for testing error handling
Is your feature request related to a problem? Please describe.
It is desirable for applications to be robust against errors not resulting from bugs but from the environment, such as:
- GPU device/driver crashes or is disconnected, or system is reconfigured in some other way
- Host environment enforces a restriction (e.g. browsers may kill WebGL contexts at any time)
- Out of memory (amount of available memory is unknown)
- The various error cases represented by
SurfaceError
However, it is likely that such handling will be missing or flawed if it is not tested.
Describe the solution you'd like
For each possible error (except for validation errors), the wgpu API should provide a means to artificially trigger this error, which can be used in automated testing of applications using wgpu. In addition to testing, this mechanism would also serve as documentation of all such possible errors.
Prior art: WebGL extension WEBGL_lose_context.
Describe alternatives you've considered
- Status quo: no additional API; application authors must resort to platform-specific and possibly manual means (if any exist) to exercise external error handling.
- Errors could be provoked not by library API but by external tools or configuration, such as environment variables. This would avoid making stability promises but would make it harder to write tests.
Something to note: DX12 has a way of removing the device but vk, metal don't actually have this. Now this would be needed for actually testing wgpu's handling of a downstream device loss. However we can add a way to force a device loss, so that our users can test their code.
Yes, this feature might have incidental benefits in testing wgpu itself, but I see it as being primarily for exercising wgpu users' code. It should be able to cause wgpu to emit all possible errors, but that does not necessarily equal the set of all error-handling/propagation paths that exist within wgpu itself.