Roadmap

[kainino0x]

The roadmap right now is basically just "get to an API-stable 1.0".

API stability probably won't officially come until we have compliant implementations in both Dawn and wgpu-native (and ideally tests). Once we have one complete implementation it'll be "probably stable".

Once we get to API stability we should have at least everything that's in the JS spec at the time of filing this issue (including things that got added after WebGPU shipped in Chrome, like rendering to a depthSlice, and the optional feature for unclippedDepth).

Eventually we expect there will be a demand for ABI stability so that libwebgpu_dawn.so and libwebgpu_wgpu.so can be interchangeable. But that will be later.

---

EDIT: An approximate finer breakdown:

• Required for 1.0
  • All breaking changes to core stuff
    • https://github.com/webgpu-native/webgpu-headers/issues?q=is%3Aissue+is%3Aopen+-label%3Anon-breaking
    • notably WGPUFuture #199
    • ExternalTexture in WASM #232 may take a bit longer to fully stabilize
    • Surface presentation stuff is low on the priority list for Dawn implementation
  • Testing (plan TBD)
  • Make sure there's nothing in the API that's inherently ABI-unstable
• Not technically required for 1.0 but important
  • Documentation! Tracking issue to write spec / explainers for native-specific parts of webgpu.h #25
• ABI Stability #282

[kainino0x]

API stability probably won't officially come until we have compliant implementations in both Dawn and wgpu-native (and ideally tests). Once we have one complete implementation it'll be "probably stable".

In Dawn's case we might still have unstable additions in the header file - depends on whether we split those into another header.

The list of things that need to be done still is here:

Right now, most of these have been discussed, and we have a resolution on them, but they're not implemented. We have a lot of implementation work to do. New small things keep coming up on the design side, but the majority of the work is implementation.

[kainino0x]

Posted a finer breakdown in the top comment.

[eliemichel]

In Dawn's case we might still have unstable additions in the header file - depends on whether we split those into another header.

I'm not aware of all the technical choices involved here, but imho in terms of documentation an lisibility for the end user of WebGPU I think it'd be great to have one and only one webgpu.h that is always the same, and put all implementation specific extensions in a separate header (like wgpu-native does in wgpu.h).

It is quite misleading that the same header may contain different things depending on circumstances and could lead to misunderstanding from people who'd like to start by "just" using WebGPU without first spending time learning about the genesis and existence of multiple backends, etc.

BTW this makes me think we should also ideally have the webgpu.h define some variables to advertise its version, because having different version would remain the only reason to end up with 2 webgpu.h files that have different content. And if we'd like to still allow backends to customize their webgpu.h then maybe we should standardize some WEBGPU_IMPLEMENTATION macro that'd be used to write code that is robust to a switch from one implem to another one.

[kainino0x]

I'm not aware of all the technical choices involved here, but imho in terms of documentation an lisibility for the end user of WebGPU I think it'd be great to have one and only one webgpu.h that is always the same, and put all implementation specific extensions in a separate header (like wgpu-native does in wgpu.h).

Yes, I think so too. TBD though, and it if does happen, it may not happen until after this upstream header is declared stabilized. (IMO Dawn can be considered "out of spec" until we do this.)