Re: "Sketch API" WebIDL

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
>