Notes from meeting with WASM WG at TPAC

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