- From: Dzmitry Malyshau <dmalyshau@mozilla.com>
- Date: Tue, 13 Feb 2018 15:40:15 -0500
- To: Corentin Wallez <cwallez@google.com>
- Cc: public-gpu <public-gpu@w3.org>
- Message-ID: <CAHnMvnJKwxsJQOjOSRPUEjjEpQhkgFO12Mc6_sLtGT=X1aOnpg@mail.gmail.com>
Hi Corentin, Thank you for writing down the sketch! here is some feedback: 1. `WebGPUBindGroupDescriptor` has a sequence of `WebGPUBinding`, each of those (I assume) corresponds to `WebGPUBindGroupBinding`. In this case, why do we need to provide start/count again? 2. Why do we need to create `WebGPUBlendState`, `WebGPUDepthStencilState`, etc blocks via `WebGPUDevice` as opposed to just passing the full descriptors (I warned about this term being ambiguous...) for ` createRenderPipeline`? Of all the backends, only Metal (and D3D11, which is out of scope) would be able to do anything meaningful in `createBlendState` and such, but there are downsides: - more API entry points - may make an false impression to the user that they are encouraged to pre-create and re-use those smaller state blocks, even though the actual behavior would hardly change, and I don't expect Metal backend to get much benefit either (to clarify: it would roughly do the same amount of work, at the same time frame, just in the backend as opposed to the user code). 3. `updateFence` is one of the opinionated API variants, since it exactly matches D3D12 and doesn't have direct Vulkan mapping As an extra clarifying question, do we have a confirmation from the WASM group that going JS-native enums would hurt WASM? Thanks, Dzmitry On Mon, Feb 12, 2018 at 4:16 PM, Corentin Wallez <cwallez@google.com> wrote: > Hey all, > > As discussed last meeting, here's a sketch WebIDL > <https://github.com/Kangz/sketchAPI/blob/master/webgpu.webidl> that's > based of NXT with controversial parts removed, leading to some > simplification. We tried to make the IDL so simple it doesn't require > explanation but we can make some documentation if things are unclear. > Obviously this is an extremely naive IDL and the goal is that the group can > use it to have more concrete discussions and make big changes to it. Large > differences from NXT are: > > - No builder, but JS-dictionnary "descriptors" instead, enums that > look like Obsidian's. > - Implicit memory barriers. > - WebGPUDevice::getQueue always return the same object. > - Apple's simple buffer upload and readback. > - Vulkan-style "multi-subpass" renderpass replaced with Metal-style > single subpass. > > The only very NXT-specific thing we kept is the binding model, and it's > "bindgroup" terminology instead of Vulkan "descriptor set". Obviously this > is nowhere close to what WebGPU should be and there's a lot of changes we'd > like to discuss: > > - Explicit memory barriers and multi-queue. > - Better tile-control. > - A different API shape that works with WASM. > - Efficient paths for buffer setsubdata and readback. > > PTAL! > > Corentin >
Received on Tuesday, 13 February 2018 20:40:41 UTC