Re: Notes from meeting with WASM WG at TPAC

Thanks Corentin for an extensive report!

In general, how was the reception of NXT demo? What where you able to show
in the end?

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?

> Callbacks into WASM are a bit of a slow path.

Let's not use callbacks then?

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

> Command buffer building will not be possible on multiple threads in
parallel

Why? I believe this is critical to get right.

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

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