Raw data into a buffer writeBuffer() MAP_WRITE buffer + mapAsync() + copyBufferToBuffer() Raw data from the network into a buffer fetch() + .arrayBuffer() + "Raw data into a buffer" Raw (uncompressed or block-compressed) data into a texture writeTexture() "Raw data into a buffer" + copyBufferToTexture()

[Serializable] interface SharedValueTable { undefined insert([EnforceRange] unsigned long long key, any value); // value must be serializable any get([EnforceRange] unsigned long long key); undefined remove([EnforceRange] unsigned long long key); }; TODO write more Keeping track of some use cases, and random thoughts

Issue: https://github.com/gpuweb/gpuweb/issues/3250 Proposal written and proposed by Kai, based on in-depth discussion with editors (Brandon/Myles/Kai) and more input from Brandon. Previous drafts Premises It should be possible for multiple "components" using the same device on the same thread to have different error scope state. It's okay if each component can't device.destroy() independently.

Proposed by editors (Myles/Brandon/Kai), and written by Brandon, with edits from Kai. An ongoing concern about use of error scopes is that they may require that operations within the scope finish in-order. At this time, it's unclear if that may prevent certain classes of optimization, such as moving pipeline creation to a separate thread. (See #2119 for prior conversation on that point.) After some discussion the editors feel that in-order resolution is not a requirement for error scopes. This document outline the reasons why, and how we feel error scopes should operate. Proposal The proposal is to remove all constraints on the ordering of the resolution of promises from popErrorScope(), relative to one another and to other promises in the API. This allows implementations use a strict ordering, resolve strictly as early as possible, or anything else. The general behavior that we would expect from an error scope is:

These are drafts. The working proposal can be found here. [TOC] Multiple components, for example multiple graph/plot widgets on a page, cannot effectively share a GPUDevice because it is stateful: It has a global error scope state, which means any error scope spanning an async boundary will capture stuff from other components. This is very difficult for an application to work around. It can be destroyed, which means one component which wants to clean up after itself cannot take advantage of GPUDevice.destroy() to do so. An application can somewhat work around this by tracking its own resource allocations, which is also more flexible for more complex ownership models (like refcounting), though that only allows freeing Buffer/Texture/QuerySet. This can be useful for some other things as well:

THIS IS A FILE FULL OF GARBAGE WRITTEN BY @kainino0x Taxonomy of WebGPU method calls This document describes different types of calls in the WebGPU API, in particular how validation and creation operations (NOT queue operations) are ordered and how errors get reported. Largely an update of https://github.com/gpuweb/gpuweb/blob/main/design/ErrorHandling.md#categories-of-webgpu-calls which is terribly outdated. Most operations in WebGPU depend on some previous operations completing. These can be modeled as carefully partially-ordered sequence of operations, but implementations most likely will fully-order

WebGPU API Missing features WebGPU features that are not supported (either the methods/enums don't exist, or produce a validation error when used): In Progress Pipeline overridable constants (dawn:1041) In ProgressGPUTextureDescriptor.viewFormats is not implemented (dawn:1276 GPUShaderModuleDescriptor.sourceMap (chromium:1177491) GPUCanvasConfiguration.colorSpace is not implemented (chromium:1241375) Postponed Pipeline statistics queries. (chromium:1177506) Done in M96 Vertex only pipelines (dawn:136)

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the deprecated and the new version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the deprecated path will result in a console warning, while when using Dawn directly, the deprecated path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have a smooth transition since developers control which version of emscripten they use. Items deprecated in this changelog will be removed in the next branched version of Chromium. They will also be removed in Chromium Canary and top of tree Dawn two weeks after this changelog is published in Canary and top of tree Dawn (so starting 2022-01-05). Previous PSAs / changelogs: Changelog for WebGPU in Chromium / Dawn 96 Changelog for WebGPU in Chromium / Dawn 94

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the deprecated and the new version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the deprecated path will result in a console warning, while when using Dawn directly, the deprecated path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have a smooth transition since developers control which version of emscripten they use. Items deprecated in this changelog will be removed in the next branched version of Chromium. They will also be removed in Chromium Canary and top of tree Dawn two weeks after this changelog is published in Canary and top of tree Dawn (so starting 2021-11-20). Previous PSAs / changelogs: Changelog for WebGPU in Chromium / Dawn 94 PSA for Chromium / Dawn WebGPU API updates 2021-04-07

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the deprecated and the new version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the deprecated path will result in a console warning, while when using Dawn directly, the deprecated path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have the smooth transition since developers control which version of emscripten they use. Items deprecated in this changelog will be removed in the next branched version of Chromium. They will also be removed in Chromium Canary and top of tree Dawn two weeks after this changelog is published in Canary and top of tree Dawn (so starting 2021-09-03). Previous PSAs / changelogs: PSA for Chromium / Dawn WebGPU API updates 2021-04-07 PSA for Chromium / Dawn WebGPU API updates 2020-10-19

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the "old" and the "new" version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the "old" path will result in a console warning, while when using Dawn directly, the "old" path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have the smooth transition since developers control which version of emscripten they use. A couple weeks after an update like this one, the "old" version will be removed. This means that the "old" version of the items below will start being removed from Chromium/Dawn starting on 2020-11-02. Previous PSAs: PSA for Chromium / Dawn WebGPU API updates 2020-07-28 PSA for Chromium / Dawn WebGPU API updates 2020-04-28

[[]] var<storage, read_write> indices : array<u32>; [[]] var<storage, read> buffer : array<u32, 3>; [[stage(compute)]] fn main() { if (iAmNaughtyInvocation) { indices[0] = 1000; } else { indices[0] = 0; }

sync vs. async

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the deprecated and the new version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the deprecated path will result in a console warning, while when using Dawn directly, the deprecated path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have the smooth transition since developers control which version of emscripten they use. A couple weeks after an update like this one, the "old" version will be removed. This means that the "old" version of the items below will start being removed from Chromium/Dawn starting on 2021-04-21. Previous PSAs: PSA for Chromium / Dawn WebGPU API updates 2020-10-19 PSA for Chromium / Dawn WebGPU API updates 2020-07-28

This document formerly held all of the unimplemented test plans. These have been moved into the gpuweb/cts repository. Further changes should be made there. The guidelines below are outdated. Contents of this document Everything in this document (once it is up-to-date with these guidelines) should be unimplemented. Once tests are in the process of being implemented, the plan moves to the description of a .spec.ts file (or to a README.txt file) in the CTS. This prevents multiple sources of information from getting

IDL tests test that the surface of the API behaves according to the rules set by WebIDL, such as optional/required arguments, argument types, numeric ranges, and so on. Note: Default value tests (for arguments and dictionary members) usually shouldn't be IDL tests. This is because it's quite difficult to check whether the default value was set or not. Instead, these can be incorporated into operation tests, which already do the hard work - all you have to do is make sure the behavior with undefined has the same expected result that you have for [default value]. IDL errors should throw exceptions. WebGPU errors should be checked not to occur by the fixture (TODO!). Helpers Helper rules for writing IDL test plans. Many of these will have helper code that implements these rules. tests for dictionaries

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, Chromium and Dawn will try to support both the "old" and the "new" version of the IDL at the same time so prototypes can be updated. In JavaScript, uses of the "old" path will result in a console warning, while when using Dawn directly, the "old" path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have the smooth transition since developers control which version of emscripten they use. A couple weeks after an update like this one, the "old" version will be removed. This means that the "old" version of the items below will start being removed from Chromium/Dawn starting on 2020-08-11. Previous PSAs: PSA for Chromium / Dawn WebGPU API updates 2020-04-28

Chromium's WebGPU implementation and Dawn's API try to closely follow changes to the WebGPU specification. When the WebGPU IDL changes, as best as possible Chromium and Dawn will support both the "old" and the "new" version of the IDL at the same time so prototypes can be updated. In JS, uses of the "old" path will result in a console warning, while when using Dawn directly, the "old" path will print a warning to stderr. Note that all changes to Dawn's API make it closer to webgpu.h that we hope will allow applications to target both Dawn, and wgpu in native before being compiled in WASM. Emscripten will also be updated from the "old" to the "new" API but won't have the smooth transition since developers control which version of emscripten they use. A couple weeks after an update like this one, the "old" version will be removed. This means that the "old" version of the items below will start being removed from Chromium/Dawn starting on 2020-05-12. Breaking changes GPUDevice .createQueue() -> .defaultQueue WebGPU PR