Re: Notes from meeting with WASM WG at TPAC

On Fri, Nov 10, 2017 at 7:14 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>
wrote:

> Thanks Corentin for an extensive report!
>
> In general, how was the reception of NXT demo? What where you able to show
> in the end?
>
> The demo session itself was a bit disappointing, there is definitely
interest in a WebGL successor but no new contacts with groups we should
collaborate with. My personal highlight was a chat with Mozilla's Luke
Wagner on more discussion of WebGPU - WASM interaction.


> A few questions about the report:
>
> > In emscriptem headers for WebGPU some function calls will have special
> attributes that make them call into the Web engine directly without going
> through JS.
>
> Assuming this is faster and desirable in general, what are the
> conditions/requirements for a function to be called directly without JS?
>
> Almost anything we would need would fall in this category, maybe with some
help from emscriptem: scalar, strings and recursively arrays and bag of
property of them should work. Callbacks too. The key is the special
attribute on the function so that emscriptem knows to put it in a special
export table.


> > Callbacks into WASM are a bit of a slow path.
>
> Let's not use callbacks then?
>
>  There was discussion on how to make them efficient with yet another
table. Callbacks should be fine outside of the hot path, so I don't think
this will put too much constraint on the design of WebGPU.


> > Some objects could be stuck on one thread by having the host binding
> table not shared. between workers.
>
> A bit of an off-topic, but it would be really interesting to see if this
> semantics could be routed from Rust directly thanks to Send/Sync traits.
>
> It seems like a great match for it yes. You could imagine a WASM
implementation of channels that build on WebWorker's MessageChannel.


> > Command buffer building will not be possible on multiple threads in
> parallel
>
> Why? I believe this is critical to get right.
>

Sorry this was unclear. Building the *same* command buffer from multiple
threads in parallel will not be possible (at least I don't think we want to
allow that).

>
> > Have a command buffer builder object that's not shareable and have built
> command buffers shareable (ok since they are immutable at that point).
>
> That matches what we have in gfx-rs. A non-sendable CommandBuffer produces
> a Submit object upon building, which is sendable.
>
> > Also this is not possible on Windows because the OS might reuse the
> virtual memory without warning.
>
> Would you have any links with more details on this behavior?
>
> Nope maybe Brad would be able to link you to some resources. Inside
Mozilla you can reach out to Luke Wagner too.


> Regards,
> Dzmitry
>
>
> On Thu, Nov 9, 2017 at 7:38 PM, Corentin Wallez <cwallez@google.com>
> wrote:
>
>> Hey all,
>>
>> Here's notes from what I remember of the meeting we had with the WASM CG
>> at TPAC. Feel free to add to it if I missed something important.
>>
>>    - Small introduction of WebGPU and the topics we'd like to talk
>>    about. Slides
>>    <https://docs.google.com/presentation/d/1eRh6I50U02CvNXTuRYnos3kMz98B2Y208LYbImwxgI4/>
>>    .
>>    - Discussion of low-overhead bindings
>>       - Exactly addressed by the Host Bindings proposal
>>       <https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md>,
>>       that also addresses JS interop. Basically select Web platform objects would
>>       be mapped to integer handles in WASM and automatically converted from/to JS
>>       objects when calling into/out of WASM. The handles would be in a new
>>       WebAssembly table.
>>       - In emscriptem headers for WebGPU some function calls will have
>>       special attributes that make them call into the Web engine directly without
>>       going through JS.
>>       - Fast Javascript style "bag of property" initializers would be
>>       possible with some additional WASM table magic but there's unresolved
>>       questions regarding how it would work for extensions that add new
>>       properties to the bag.
>>       - Enum / bitfields as arguments should work fine.
>>       - Callbacks into WASM are a bit of a slow path. Discussion of
>>       additional WASM table magic to make them efficient. The table might need to
>>       store a userdata pointer in addition to a function pointer.
>>    - Multithreading
>>       - In WASM starting a thread works by creating a Web Worker,
>>       sending it the SharedArrayBuffer for the main memory and starting the
>>       module again on the same SharedArrayBuffer.
>>       - It isn't clear yet how it will interact with the "host bindings"
>>       proposal. WebGPU objects could be tagged as "shareable" in which case the
>>       host binding table would be shareable too, and could be sent along with the
>>       SharedArrayBuffer.
>>       - Some WebGPU objects like queues will be callable anytime from
>>       any thread and will have a mutex internally.
>>       - Some objects could be stuck on one thread by having the host
>>       binding table not shared. between workers.
>>       - Command buffer building will not be possible on multiple threads
>>       in parallel but they will often be built and submitted on different
>>       threads. Possibilities to make this happen are:
>>          - Have the builder thread "send" the command buffer to the
>>          submission thread after it is built.
>>          - Make the command buffer building commands check they are on
>>          the correct thread and trap otherwise.
>>          - Have a command buffer builder object that's not shareable and
>>          have built command buffers shareable (ok since they are immutable at that
>>          point).
>>          - Suggestion that command buffer creation could use an
>>          in-memory command buffer format so that there is a single "CommandBuffer
>>          Build(void*ptr, size_t len)".
>>       - Memory mapping in the WASM memory space.
>>       - To achieve the minimum number of copies when uploading /
>>       downloading to the GPU, WebGPU would love to be able to map memory directly
>>       into the WASM heap. For example an application could decompress data
>>       directly into a GPU-visible buffer.
>>       - For reasons, only file descriptors can be mapped this way, not
>>       arbitrary pointers. Also this is not possible on Windows because the OS
>>       might reuse the virtual memory without warning. (WebGPU would be a good
>>       use-case to push Microsoft to change that)
>>       - So the mapping APIs will need to be transparent to whether
>>       actual mapping is used, or copies performed by the browser.
>>       - We'll also need to make sure to avoid races with the GPU, WebGPU
>>       has ideas on how to do that.
>>       - Also the browser doesn't know which memory is free in the WASM
>>       heap so things would be more like the following in WASM (could be made
>>       transparent by emscriptem):
>>          - void* ptr = malloc(size);
>>          - buffer.WouldYouKindlyMapHere(ptr, size);
>>          - Do stuff with ptr
>>          - buffer.Unmap();
>>          - free(ptr);
>>
>>
>