Repository navigation
Roadmap #281
Description
Activity
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.
- pinned this issue
on Mar 7, 2024 Posted a finer breakdown in the top comment.
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.hthat is always the same, and put all implementation specific extensions in a separate header (like wgpu-native does inwgpu.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.hfiles that have different content. And if we'd like to still allow backends to customize theirwebgpu.hthen maybe we should standardize someWEBGPU_IMPLEMENTATIONmacro that'd be used to write code that is robust to a switch from one implem to another one.Reacted by Kai NinomiyaI'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.hthat is always the same, and put all implementation specific extensions in a separate header (like wgpu-native does inwgpu.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.)
Reacted by Elie MichelDec 19 meeting:
- Updates
- KN: Very few changes to make after last few meetings because mostly closed things. However there are a few docs to write (in addition to various other docs we still need to write) and I haven't gotten to them just yet. I have gone over the open issues though and I don't think I'm likely to find any more big things to discuss. We are very nearly stable! I plan to:
- Add docs for everything in "needs docs" to find any missing details
- Review all of the things labeled "non-breaking" to make sure they really are
- KN: Very few changes to make after last few meetings because mostly closed things. However there are a few docs to write (in addition to various other docs we still need to write) and I haven't gotten to them just yet. I have gone over the open issues though and I don't think I'm likely to find any more big things to discuss. We are very nearly stable! I plan to:
- Discussion: Tagging a "release candidate"
- > If any of the try-for-v1 things gets standardized very soon in W3C (TBH unlikely), should we add them even after release candidate? Adding things to structs unfortunately still commonly causes breakage.
- (Forgot to discuss this but it's not important, can discuss it if it actually comes to pass)
- > Should someone from wgpu do a pass over the whole header?
- KN: What should we do in order to call something a release candidate? We also haven’t finished implementing it on our side, so probably wait until we finish an implementation to call it?
- CF: Unlikely to find any problem just scrolling through, probably would need to start implementing.
- KN: Dawn-side is pretty far along, but still some migrations and stuff necessary. We won’t be sure about the release candidate until we finish. We don’t need to officially tag a candidate, but we should say that this is the target?
- CF: Doubts there will be any time to work on the implementation on wgpu side. Also not sure if @rajveermalviya is around to work on it? Probably just needs work, and shouldn’t be too big a problem, though wgpu might need some refactor to make it work.
- Dawn will probably run into most things first if anything.
- KN: If anyone on wgpu native side is interested in implementing, would be nice. Is there a tracking bug on wgpu native to match webgpu.h?
- CF: Likely to exist? But probably not updated?
- KN: Found a bug for wgpu-on-webgpu.h but didn't find one for making wgpu-native conform to webgpu.h.
- > If any of the try-for-v1 things gets standardized very soon in W3C (TBH unlikely), should we add them even after release candidate? Adding things to structs unfortunately still commonly causes breakage.
- aside: why wgpu-on-webgpu.h?
- CF: I closed the wgpu bug about that, don't think it will happen. Would be interesting for performance comparison though.
- (Discussion of relative performance)
- Barrier generation
- Dawn surprisingly fast when skipping validation. How we skip validation
- Refcounting overhead
- wgpu has asserts that fire if (debug build || firefox)
- CF will be working on d3d12 sampler heap idea using bindless (contrast with the approach 11on12 and dawn use of just-in-time heap re-allocation)
- Updates
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: