Re: "Sketch API" WebIDL

Also I've created a pull request on the gpuweb/gpuweb repo
<https://github.com/gpuweb/gpuweb/pull/47> with the sketch WebIDL to make
it easier for folks to comment when corporate policies whitelist Github
repos.


On Tue, Feb 13, 2018 at 5:54 PM, Corentin Wallez <cwallez@google.com> wrote:

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