Re: "Sketch API" WebIDL

Hey Dzmitry, thanks for the feedback!

On Tue, Feb 13, 2018 at 3:40 PM, Dzmitry Malyshau <dmalyshau@mozilla.com>
wrote:

> 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?
>

The only reason is that it makes it slightly more clear at WebGPUBindGroup
creation time what goes where. You are correct that this is redundant
because the WebGPUBindGroup has to match its WebGPUBindGroupLayout.
Removing them makes the API a bit ugly so I'm not 100% sure what to do
there for the best user experience.

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).
>

Yeah "descriptor" is very overloaded, just imagine how it would be with
descriptor sets / descriptor heaps too :) There are maybe tiny benefits to
doing this but we should debate of it once we have a sketch API to work
with. It doesn't seem like these are super strong objections and it would
be easy to change this aspect of the API so let's defer discussion to after
we have a sketch, WDYT?


> 3. `updateFence` is one of the opinionated API variants, since it exactly
> matches D3D12 and doesn't have direct Vulkan mapping
>
> Likewise this can be super easily changed so let's defer?


> As an extra clarifying question, do we have a confirmation from the WASM
> group that going JS-native enums would hurt WASM?
>
> You mean "string" enums? We haven't asked anything so I don't know.


> 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
>>
>
>
Corentin